Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Vuln-Dev
[Top] [All Lists]

Re: DJB's students release 44 *nix software vulnerability advisories

Subject: Re: DJB's students release 44 *nix software vulnerability advisories
Date: Fri, 24 Dec 2004 01:29:32 -0800
D. J. Bernstein wrote:

Crispin starts from these three examples of intrusions occurring _after_
full disclosure, and---applying the principle ``post hoc, ergo propter
hoc''---leaps to the astounding conclusion that the intrusions were
_caused_ by full disclosure, i.e., that avoiding disclosure would have
prevented the intrusions.


You are right, it is circumstantial evidence. But it is mighty strong circumstantial evidence. Brown et al only study three vulnerabilities, but it is not an uncommon result. Reportedly a primary reason that Microsoft switched to monthly disclosures is that they were seeing a bloom of malware attacks following every single disclosure, and they wanted to batch them up to get control of those blooms.

Crispin's conclusion is obviously incorrect. We've all seen reports of
extensive damage caused by attackers exploiting security holes that
_weren't_ publicly known before the attacks. Clearly the attackers are
capable of reading software and finding security holes for themselves.
This isn't rocket science.


That you can find instances of something other than full disclosure causing a bloom of attacks does not invalidate the inference that full and *abrupt* disclosure can cause a bloom of attacks. It just means that full disclosure is not the *only* cause of a bloom. The above logic is obviously faulty, even if it does include Latin words :)

However, if I may offer a different criticism of my own claim, there is a question of the evidence of positive benefits of responsible disclosure. Rescola presents data http://www.usenix.org/events/sec03/tech/rescorla.html that even with a well-timed responsible disclosure of a major vulnerability (OpenSSL chunking bug) many many people just never bothered to patch. However, this study concerns only a single vulnerability, and it is possible that OpenSSL was not widely patched because it is reputed to be a difficult upgrade to perform correctly.

There is, by the way, a more subtle problem with the argument against
full disclosure: the argument focuses entirely on short-term effects and
ignores long-term effects.

Forcible disclosure with a time like as specified in the RFPolicy http://www.wiretrip.net/rfp/policy.html would seem to have nearly identical long-term effects with much less damaging short-term effects. Is it your contention that a "patch up or else" disclosure policy like the RFPolicy does *not* cause programmers to clean up their act? Can you justify how abrupt disclosure encourages any better behavior than timed disclosure at the discretion of the bug-finder?

But the basic problem with the argument is
that it's out of whack with reality. If you think that hiding security
information keeps us safe, you're deluding yourself.


But I *do not* think that hiding security information keeps us safe. Rather, I think that disclosing vulnerability information has impact on attackers and defenders, and the *timing* of that disclosure, especially with respect to the availability of a patch, has critical impact on who it impacts and how much.

Crispin

--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix          http://immunix.com

<Prev in Thread] Current Thread [Next in Thread>