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] [thread-next>] [day] [month] [year] [list]
Message-ID: <46F5FACF.9010807@novell.com>
Date: Sat, 22 Sep 2007 22:34:07 -0700
From: Crispin Cowan <crispin@...ell.com>
To: Casper.Dik@....COM
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	"pdp \(architect\)" <pdp.gnucitizen@...glemail.com>,
	Gadi Evron <ge@...uxbox.org>
Subject: Re: 0day: PDF pwns Windows

Casper.Dik@....COM 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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ