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>] [day] [month] [year] [list]
Date: Wed, 22 Dec 2004 15:08:36 -0800
From: Crispin Cowan <crispin@...unix.com>
To: robert@...dsecurity.com
Cc: "D. J. Bernstein" <djb@...yp.to>, bugtraq@...urityfocus.com
Subject: Re: DJB's students release 44 *nix software vulnerability advisories


robert@...dsecurity.com wrote:

>What you have to ask yourself here is what do you fear more?:
>A) Do you fear wide spread worm based attacks where everyone knows about
>the problems at about the same time, and is more annoying than
>devistating?
>
>B) Do you fear directed malice attacks using information that that the
>defense does not know about?
>
>For my customers I fear B far more than A.
>  
>
Lets do the math. The vulnerable code has been around for a year. A 
vulnerability is discovered. The software provider wants 2 weeks. Lets 
say (generously) that there are 10 times as many SOHO users defending 
against A as there are critical infrastructure users defending against B.

    * If we do A (responsible disclosure) then we expose (say) X users
      to 2/50 additional weeks of time in which an el33t hax0r has a
      private 0day against them that might be deployed, so you get
      X*0.04 of time/risk exposure.
    * If we do B (full disclosure), then we save the critical
      infrastructure people that X*0.04 risk days, and instead we get
      the 10X of SOHO users exposed to 2 weeks in which there is no
      patch available. Assume that the software had another year of
      lifespan before it was obsoleted, so again there is a factor of
      2/50 or 0.04 on the risk days, but there are 10X users, so the
      total risk factor is X*0.4.

Netted out, the risk/benefit is roughly the same but multiplied by the 
size of the respective communities, and the SOHO community is much, much 
larger.

I further submit that not all critical infrastructure people agree with 
you, and some would rather see responsible disclosure of 
vulnerabilities. You can tell by the number of enterprises subscribing 
to early warning services for responsible disclosure for big $$$.


>The stick your head in the sand approach to Vulnerability Disclosure is
>not the direction I want to see the industry go.
>  
>
Neither is a colloquial ad homenim approach to describing your opponents 
pie in the sky position :)

>> Furthermore, if you force a fire drill in releasing the security
>>patch, you compromise the quality of the patch. See my work on patch
>>quality "Timing the Application of Security Patches for Optimal
>>Uptime", Beattie et al Postscript
>><http://immunix.com/%7Ecrispin/time-to-patch-usenix-lisa02.ps.gz>. or
>>ugly PDF
>><http://immunix.com/%7Ecrispin/time-to-patch-usenix-lisa02.pdf>.
>>    
>>
>Perhaps a Patch isn't the only option here.  Perhaps changing vendors,
>or removing the vulnerable service is an alternative to being
>compromised, or installing a buggy patch.  No matter what, without the
>vulnerability information, you are making an uninformed decision.
>  
>
Indeed. Another approach is to deploy intrusion prevention technologies 
such as Immunix <http://immunix.com/technology/> that can block 0-day 
attacks without needing any specific knowledge of whatever DJB's class 
will come up with next time.

>>So while I am sympathetic to DJB's passion for correct software and to
>>hell with the tender feelings of developers who ship buggy code, in
>>practice this kind of 0-day notice of vulnerabilities *mostly* just
>>harms end-users.
>>    
>>
>I think this depends on the segment you're talking about.  If you're
>talking about enterprise or mission critical systems, full disclosure
>should help the end user more than hurt, as they are more likely to have
>the resources available to take appropriate action.  If you're talking
>about soho/home PC users, then I would agreee with your point above.
>  
>
More precisely, if you are talking about a service that can be *taken 
down* while waiting for a fix or a work-around, then full disclosure is 
an advantage. If the service cannot (or will not) be taken down and will 
be just left to run the risk of compromise, then responsible disclosure 
helps. I submit that most enterprise systems are of the "damn the 
torpedoes" school of thought.

>The delima for me only comes when the enterprise/mission critical
>infrastructure is the same as the home/soho infrastructure.
>  
>
Microsoft: shared between SOHO and Enterprise
Linux: shared between SOHO and Enterprise
Solaris: Enterprise only, but declining share, rapidly being replaced 
with Microsoft and Linux

This does not make me feel better about full disclosure :)

Big fat caveat: All of the above assumes that the investigator is 
actually well-intentioned. Actual black hats will do whatever they want, 
and what we all advocate is of no matter, so defenders have to be able 
to withstand 0-days anyway.

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