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-next>] [day] [month] [year] [list]
Date: Wed, 13 Jun 2007 13:03:36 -0400 (EDT)
From: "Steven M. Christey" <coley@...us.mitre.org>
To: bugtraq@...urityfocus.com
Subject: Re: Windows Oday release


Joanna Rutkowska said:

>> Dear all, this is not a 0day, it is a public release of a responsibly
>> disclosed vulnerability.
>>
>
>Yes, indeed it *seems* so:
>http://www.microsoft.com/technet/security/Bulletin/MS07-031.mspx

The kinds of discrepancies you list are an almost daily occurrence with
many vendors.  I can't begin to imagine how many sysadmins and even
security researchers make assumptions that link two separate issues just
because they happen to involve the same component.

Some sufficient correlators are:

 - cross-references (CVE, Bugtraq ID, Secunia, OSVDB, etc.)

 - claims by reliable parties (for some definition of "reliable") that the
   vendor's advisory fixes issue X

 - sufficient details in both vendor and researcher advisory WITH
   ATTACK VECTORS ("buffer overflow in component X doesn't cut it")

 - mutual credits and date-of-disclosure coordination

 - private verification by vendor

Any one of these is usually enough.

Doing this correlation is one of the significant value-adds of refined
vulnerability information providers, by the way.

>The time line is also interesting, BTW:

Disclosure timelines are some of the most entertaining and educational
reading in security advisories.  There's now (finally) enough data for
somebody somewhere to do a quantitative study on reported timelines,
including typical vendor response times, and issues in the process.  (If
someone wants to pursue this, feel free to contact me to bat ideas
around.)

A lot of researcher timelines show a delay between the original discovery
and vendor notification.  In some cases, this can be due to additional
time required to prove that the discovery is exploitable in order to give
a more reliable report to the vendor, but that's not always the case.

- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ