Message-Id: <200707181653.l6IGr9GX009495@mail-1.llnl.gov>
Date: Wed, 18 Jul 2007 09:53:09 -0700
From: "Zow" Terry Brugger <zow@...l.gov>
To: Chris Stromblad <cs@...post24.com>
Cc: Gadi Evron <ge@...uxbox.org>, bugtraq@...urityfocus.com
Subject: Re: Internet Explorer 0day exploit 

> What exactly constitutes a 0day? From my perspective naming a
> vulnerability 0day have absolutely no value whatsoever, it just doesn't
> make any sense. 0day for who? The person who release it, sure, but for
> the security community as a whole... nah.

I consider a "0day" to be a vulnerability for which there is an exploit in 
the wild before there's a vendor patch for the problem. If this convention is 
followed, it has value to the community, because we know that having that 
software on our systems presents a significant risk.

> I'm also personally starting to question the whole idea behind public
> disclosure and advisories. Do they actually mean anything these days?
> What good is it to know about a vulnerability that was "discovered" 6
> months ago? The important thing is to know what can be done BEFORE the
> patch has been released.

I presume you're talking about the situations where the researcher has 
coordinated their advisory release with the vendor such that vulnerability 
details are not disclosed before a patch is available. Yes, I still think 
these advisories are valuable because they often provide more details about 
what was broken than the vendor advisories do (which often read, "There's a 
security problem in product X. Install this patch."). Such details allow us 
to learn what goes wrong when building software systems and allows us to 
avoid such problems in the future. Occasionally the advisories from the 
researchers also provide some insight into how they found the vulnerabilities 
(although I've seen this decreasing in recent years), which helps others 
learn how to find vulnerabilities.

> Also a big portion of "advisories" seem to be related to the most
> obscure softwares and home made PHP applications that most of us never
> even care about anyway. These advisories clutter the ones that have even
>  the slightest validity.

To some extent, I agree. At the same time though, I think these tend to come 
from people who are learning how to do vulnerability analysis, starting with 
the low hanging fruit. To that end, I think the ability for these people to 
get peer-reviewed feedback on their work is immensely useful to the community 
as a whole.

> One more thing about "advisories". I think it would be better to release
> them immediately and let people know what they are facing. With public
> dissemination of a vulnerability perhaps someone will release a 3rd
> party patch or another inventive way of protecting oneself. Holding it
> "secret" really doesn't help anyone. If anything it prevents people from
>  trying to find a way to fix the vulnerability.

First off, I don't think anyone can seriously say it doesn't help _anybody_ 
-- it certainly helps the vendor. If it's an IDS/IPS company that holds the 
research and they've got a signature out for it on their system, it certainly 
helps them. Here we find a variation on the ancient (in Internet terms) 
argument about full disclosure: if bugs are public knowledge, will vendors be 
more responsive to fixing them? I don't think you're going to see publicly 
developed patches for any but the most extreme cases. At the same time, I see 
some advisories where the vendor was notified more than six months ago and 
just has a patch out now. That's a pretty large window of vulnerability if 
anyone malicious knows about the problem (and if we're finding them in the 
open community, there's no reason they wouldn't). I think security 
researchers need to continue to think about exuding due pressure on vendors 
to get bugs patched.

My two-bits,
Terry

#include <stddisclaimer.h>

Powered by blists - more mailing lists