It’s that time again: time for USENET FULL DISCLOSURE DEBATE!

Thomas Ptacek | May 21st, 2005 | Filed Under: Uncategorized

Doug Gwyn: however, the thing to do first is to notify a CERT and let them work on getting existing products fixed before you alert the general public (meaning the attackers).

Doug Gwyn comes to us live from the year 1991. Boy is he going to be pissed when he finds out about Bugtraq.

Colin Percival: all that matters as far as computer security is concerned is fixing the problem in a manner which results in as little risk as possible.

From Wikipedia: Risk is the potential harm that may arise from some present process or from some future event. I guess Robert McHenry was right; it really is a “faith-based encyclopedia”. Better go edit those last 5 words out.

Or maybe Colin’s argument is that there won’t be any more vulnerabilities after his; or maybe that we simply have no influence over them?

Paul Rubin: Designers and implementers doing anything security related generally do their best not to leave holes …

Thanks for playing, Paul.

David Wagner: the best bug-disclosure policy to follow is an optimization problem

So the best response to the discovery of a critical security vulnerability is to get a party who has virtually no concrete information about the extent to which important organizations (banks, military installations, homestarrunner.com) are exposed to a threat together with a party who has virtually no incentive to see their broken software maligned in public, and trust them to “optimize” the disclosure to the benefit of sysadmins everywhere.

Let’s grant the notion that vulnerability disclosure can be optimized to the benefit of the typical sysadmin. Why is this the best possible outcome for us? Isn’t there a better possible outcome wherein organizations who are exposed to vulnerabilities can quickly make the decision to disable the broken software to mitigate their exposure, in advance of a well-tested patch? For example:

Casper Dik: *There’s no proof that the “immediate disclosure” has a stronger effect on the improving software quality than “disclosure at some later time”.

Casper ought to know better. In fact, wait, Casper does know better; he worked in security at Sun when they while they were patient zero in the successive epidemics of integer overflows, race conditions, metacharacter expansions, and buffer overflows. Casper knows that if we installed SunOS 4.1.3U1 from 1995 on a reachable IP address today it would take less than 72 hours for it to be broken into.

Of course, Casper’s not arguing against disclosure —- just “undisciplined” disclosure, like the kind where you don’t sit and wait for 8 months while the vendor beta-tests the patch they come up with. What Casper isn’t acknowledging is that, during the time when his company was making security teams sit on their hands during the 90’s, there was plenty of “undisciplined” disclosure occurring, such as the disclosure of the rpc.statd NFS vulnerability and the ToolTalk vulnerability, which were exploited for years before being announced.

The irony here is, unless you were using ToolTalk (if you haven’t heard of it, you weren’t relying on it) or NFS file locking (even if you have heard of it, you weren’t really relying on it), you were only superficially exposed to these problems: all you had to do was turn the services off.

But the people I’m quoting don’t believe you should be able to make those decisions. Some people were relying on ToolTalk: if we disclosed the vulnerability without making a patch available, they’d could be held liable for not incurring the business cost of disabling the vulnerable service rather than accepting their exposure to a known threat. Best not to force such uncomfortable judgement calls, and let CERT and the vendors make it for them.

Casper continues, “We have no data, just suppositions.” We don’t have data? What have SecurityFocus, X-Force, Bugtraq, and Secunia been doing for the last 7 years? We do so have data: this argument just says you’re too lazy to mine it for evidence to support your conclusion. The real problem is that the data doesn’t support your argument; vulnerability research by groups like eEye and OpenBSD have drastically improved the security of popular software.

Casper is a very smart person. Some of the people participating in this sci.crypt thread aren’t so smart. If it weren’t for participants like Casper and David Wagner, I’d be tempted to believe that none of the posts in this debate come from people who have ever handled a major vulnerability disclosure (no, Paul, elm doesn’t count). What do these people think about the (prevalent) practice of selling vulnerability information to the highest bidder?