lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 24 Dec 2004 01:29:32 -0800
From: Crispin Cowan <crispin@...unix.com>
To: "D. J. Bernstein" <djb@...yp.to>
Cc: bugtraq@...urityfocus.com
Subject: Re: DJB's students release 44 *nix software vulnerability advisories


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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ