Partial disclosure

We are increasingly seeing disclosures of security vulnerabilities that don't actually disclose much, except that the researcher has found something. Unfortunately, we have also seen lots of evidence that once the presence of a flaw is known, it doesn't take very long for folks to figure out what the vulnerability is. Of course, we don't have any data on how long it takes those with a malicious intent to find the flaws, but clearly the "white hats" find them quickly. So what or who, exactly, are those practicing "partial disclosure" protecting?

Partial disclosure is clearly a part of the "security circus" that Linus Torvalds recently castigated, as it serves to increase the notoriety of security researchers, without necessarily doing anything to help protect users. Several recent examples come to mind of researchers who have found real flaws, but for various reasons don't want to disclose the details. Instead they "tease" the world by talking around what they found, trying—and generally failing—to leave out enough information so that others can't immediately follow in their footsteps.

Dan Kaminsky's DNS flaw was an interesting example in that Kaminsky only disclosed the vulnerability to affected software vendors, allowing them multiple months to produce patches. He then wanted to give administrators time to apply the patches so he delayed disclosing the flaw for another month or so. He also had an admittedly selfish reason for delaying disclosure: he wanted to announce it at the Black Hat security conference.

Because of the addition of source port randomization as the fix, it didn't take very long for other security researchers to come up with the vulnerability. Attackers may have come up with it even more quickly, but because there were no details available, developers of other, smaller DNS servers—not privy to the initial disclosure—were unable to determine whether their code was vulnerable. It is commendable that Kaminsky worked with the vendors to fix the problem, but there were clearly holes in his disclosure methods.

A worse case can be seen with the recent spate of reports about "clickjacking". It started with a report of a canceled talk at the OWASP AppSec conference. The name is clearly suggestive of where the vulnerability might be, and the description of the canceled talk gave enough information that others were able to duplicate it. This led one of the original researchers to release the vulnerability information.

So, in the interim, there was enough information floating around to find and exploit the flaws, and now the vulnerability info has been released, but there are no fixes available for many of them. It is hard to see what delaying the disclosure did for anyone—researchers or users—here. It did generate lots of press, though, partially because of the name as Bruce Schneier pointed out pre-disclosure:

Yet another recent example is the denial of service reported for nearly any TCP device. Like clickjacking, it is being described in scary ways—which may well be justified:

There may well be enough information in the description of what the researchers found—and, in particular, how they found it—for an enterprising attacker to find it for themselves. In the meantime, the rest of us are left in the dark. Security researchers are clearly under no obligation to disclose their research sensibly, but it would seem that either releasing all the details at once, or keeping them completely secret, would be better than these partial disclosures.