Hi Crispin, I agree with almost everything you say until here: "I continue to dismiss the requirement that an 0day be found maliciously exploiting machines, because that requires inferring intent." IMO, everybody in this thread is taking this from an inside-to-outside approach, whereas a '0day' is the opposite. If I'm on a CERT team for a corporation then I don't give a flying F if somebody's concocted a cool exploit for a vulnerability that hasn't been patched; and moreover, I don't know about it. I only care if there's malicious code running around in the real world doing damage that has no patch for the vulnerability. That's when I have to take some action or be completely helpless and in my mind that's the only time I consider a '0day' to have any relevance. Let me repeat: if it's a theoretical exploit, or even if it's hit 100,000 machines but has not been reported and is not "being in the wild", then it has no relevance to me BECAUSE I DON'T KNOW THAT IT EXISTS and therefore to me it is not 0day. Only through normal channels doing my daily CERT work (dCERT, FrSIRT, Secunia, etc.) if I see an exploit on an unpatched vulnerability doing real damage is when I would ever consider the term '0day'. Very respectfully, Ignacio --- Crispin Cowan <crispin@xxxxxxxxxx> wrote: > Casper.Dik@xxxxxxx wrote: > >> But then there is the important concept of the "private 0day", a > new > >> vulnerability that a malicious person has but has not used yet. > >> > > But the point is there is no such thing as a 0day > *vulnerability"; there's > > a 0day exploit, an exploit in the wild before the vulnerability > id > > discovered. > > > An excellent point. Sorry I overlooked that. Exploit development > today > is so fast that I tend to equate knowledge of a vulnerability with > "... > and can have an exploit by tomorrow afternoon." > > >> Rather, I just treat "0day" as a synonym for "new vulnerability" > and > >> don't give a hoot about the alleged intentions of whoever > discovered it. > >> What makes it an "0" day is that whoever is announcing it is > first to > >> announce it in public. You could only invalidate the 0day claim > by > >> showing that the same vulnerability had previously been > disclosed by > >> someone else. > >> > > The point is that it is not supposed to be moniker for > vulnerabilities; > > it's a moniker for exploits. In any other context it does not > make sense. > > > > Specifically considering that "0-day exploit" is the only > definition which > > holds meaning with respect to a particular exploit over time. > "An exploit > > which existed before the vulnerability was publicly known". > > > Yes, you are right. So "0day" is a class of exploits. Specifically, > it > is the class of exploits that are developed before the first > available > patch for the vulnerability in question. > > But that race condition of whether the patch or the exploit is > partially > ordered, because they could be developed independently. There is > the > special case where the person who first discovered the > vulnerability > also develops either a patch or an exploit, in which case it is > totally > ordered. But in the general case where one person discovers the > vulnerability, and two other people independently develop an > exploit and > a patch, you can't tell who finished first. All you can do is > detect who > published first. > > So fair enough, an "0day exploit" is one that appears in public > before > the associated patch is published. > > A "private 0day exploit" (the case I was concerned with) would be > where > someone develops an exploit, but does not deploy or publish it, > holding > it in reserve to attack others at the time of their choosing. > Presumably > if such a person wanted to keep it for very long, they would have > to > base it on a vulnerability that they themselves discovered, and did > not > publish. > > I continue to dismiss the requirement that an 0day be found > maliciously > exploiting machines, because that requires inferring intent. IMHO, > a POC > exploit first posted to Bugtraq ahead of the patch counts as an > 0day > exploit, unless it has been so thoroughly obfuscated that the > "proof" > part of "proof of concept" is itself BS. > > Crispin > > -- > Crispin Cowan, Ph.D. > http://crispincowan.com/~crispin/ > Director of Software Engineering http://novell.com > AppArmor Chat: irc.oftc.net/#apparmor > > ____________________________________________________________________________________ Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658
