Three weeks ago, a serious security issue in OS X 10.10.4 was discovered. That, in itself, isn’t particularly interesting.
Security vulnerabilities in popular software packages are discovered all the time, and OS X is no exception. The Open Source Vulnerability Database (OSVDB) shows at least 1100 vulnerabilities tagged as “OS X”. But what is interesting is the way in which this particular vulnerability was disclosed.
Rather than tell Apple and give them time to remedy the problem, the researcher decided to post his exploit on the Internet for everyone to see.
The end result was an arms-race between Apple and black-hat hackers. Apple had to release a patch before the vulnerability was weaponized, and the hackers had to create an exploit before the at-risk systems get patched.
You might think that particular method of disclosure is irresponsible. You could even call it unethical, or reckless. But it’s more complicated than that. Welcome to the strange, confusing world of vulnerability disclosure.
Full vs Responsible Disclosure
There are two popular ways of disclosing vulnerabilities to software vendors.
The first is called full disclosure. Much like in the previous example, researchers immediately publish their vulnerability into the wild, giving the vendors absolutely no opportunity to release a fix.
The second is called responsible disclosure, or staggered disclosure. This is where the researcher contacts the vendor before the vulnerability is released.
Both parties then agree on a time frame where the researcher promises not to publish the vulnerability, in order to give the vendor an opportunity to build and release a fix. This time period can be anywhere from 30 days to a year, depending on the severity and complexity of the vulnerability. Some security holes cannot be fixed easily, and require entire software systems to be rebuilt from scratch.
Once both parties are satisfied with the fix that’s been produced, the vulnerability is then disclosed and given a CVE number. These uniquely identify each vulnerability, and the vulnerability is archived online on the OSVDB.
But what happens if the waiting time expires? Well, one of two things. The vendor will then negotiate an extension with the researcher. But if the researcher is unhappy with how the vendor has responded or behaved, or they feel the request for an extension is unreasonable, they might simply publish it online with no fix ready.
In the security field, there are heated debates as to what method of disclosure is best. Some think that the only ethical and accurate method is full disclosure. Some think that it’s best to give vendors an opportunity to fix a problem before releasing it into the wild.
As it turns out, there are some compelling arguments for both sides.
The Arguments In Favor Of Responsible Disclosure
Let’s look at an example of where it was best to use responsible disclosure.
When we talk about critical infrastructure within the context of the Internet, it’s hard to avoid talking about the DNS protocol. This is what allows us to translate human-readable web addresses (like makeuseof.com) into IP addresses.
The DNS system is incredibly complicated, and not just on a technical level. There’s a lot of trust placed in this system. We trust that when we type in a web address, we’re sent to the right place. There’s simply a lot riding on the integrity of this system.
If someone was able to interfere with, or compromise a DNS request, there is a lot of potential for damage. For example, they could send people to fraudulent online banking pages, thereby allowing them to obtain their online banking details. They could intercept their email and online traffic through a man-in-the-middle attack, and read the contents. They could fundamentally undermine the security of the Internet as a whole. Scary stuff.
Dan Kaminsky is a well respected security researcher, with a long resume of finding vulnerabilities in well-known software. But he’s most well known for 2008’s discovery of perhaps the most severe vulnerability in the DNS system ever found. This would have allowed someone to easily perform a cache poisoning (or DNS spoofing) attack on a DNS name server. The more technical details of this vulnerability were explained at the 2008 Def Con conference.
Kaminsky, acutely aware of the consequences of releasing such a severe flaw, decided to disclose it to the vendors of the DNS software that are affected by this bug.
There were a number of major DNS products affected, including those built by Alcatel-Lucent, BlueCoat Technologies, Apple and Cisco. The issue also affected a number of DNS implementations that shipped with some popular Linux/BSD distributions, including those for Debian, Arch, Gentoo and FreeBSD.
Kaminsky gave them 150 days to produce a fix, and worked with them in secret to help them understand the vulnerability. He knew that this issue was so severe, and the potential damages so great, that it would have been incredibly reckless to publicly release it without giving the vendors an opportunity to issue a patch.
Incidentally, the vulnerability was leaked by accident by security firm Matsano in a blog post. The article was taken down, but it was mirrored, and one day after publication an exploit had been created.
Kaminsky’s DNS vulnerability ultimately sums up the crux of the argument in favor of responsible, staggered disclosure. Some vulnerabilities – like zero day vulnerabilities – are so significant, that to publicly release them would cause significant damage.
But there’s also a compelling argument in favor of not giving advance warning.
The Case For Full Disclosure
By releasing a vulnerability into the open, you unlock a pandora’s box where unsavory individuals are able to rapidly and easily produce exploits, and compromise vulnerable systems. So, why would someone choose to do that?
There are a couple of reasons. Firstly, vendors are often quite slow to respond to security notifications. By effectively forcing their hand by releasing a vulnerability into the wild, they’re more motivated to respond quickly. Even worse, some are inclined to not publicize the fact they were shipping vulnerable software. Full disclosure forces them to be honest with their customers.
Apparently @PepsiCo doesn't care about a vuln in their site, not accepting unsolicited help. Already has a sec team. I'll do full disclosure
— White Packet (@WhitePacket) September 4, 2015
But it also allows consumers to make an informed choice as to whether they want to continue to use a particular, vulnerable piece of software. I would imagine the majority would not.
What Do Vendors Want?
Vendors really dislike full disclosure.
After all, it’s incredibly bad PR for them, and it puts their customers at risk. They’ve tried to incentivize people to disclose vulnerabilities responsibly though bug bounty programs. These have been remarkably successful, with Google paying $1.3 million dollars in 2014 alone.
Although it’s worth pointing out that some companies – like Oracle – discourage people from performing security research on their software.
But there are still going to be people who insist on using full disclosure, either for philosophical reasons, or for their own amusement. No bug bounty program, no matter how generous, can counter that.