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. |

| 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_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.
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.
Crispin's conclusion is obviously incorrect. We've all seen reports ofThat 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 :)
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.
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?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.
But the basic problem with the argument isBut 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.
that it's out of whack with reality. If you think that hiding security
information keeps us safe, you're deluding yourself.
Crispin
-- Crispin Cowan, Ph.D. http://immunix.com/~crispin/ CTO, Immunix http://immunix.com
| Previous by Date: | [SECURITY] [DSA 618-1] New imlib packages fix arbitrary code execution, Martin Schulze |
|---|---|
| Next by Date: | Re: DJB's students release 44 *nix software vulnerability advisories, David Wagner |
| Previous by Thread: | Re: DJB's students release 44 *nix software vulnerability advisories, D. J. Bernstein |
| Next by Thread: | Re: DJB's students release 44 *nix software vulnerability advisories, Crispin Cowan |
| Indexes: | [Date] [Thread] [Top] [All Lists] |