bugtraq - Re: The newest Word flaw is due to malformed data structure handling

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, 13 Dec 2006 21:06:10 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com
Subject: Re: The newest Word flaw is due to malformed data structure handling

Alexander Sotirov said:

>Descriptions of vulnerabilities, especially ones that are found in the
>wild, should include enough information to allow researchers to
>uniquely identify the new vulnerability and differentiate it from all
>other bugs, both known ones and 0days.

I say this periodically, e.g. in [1], but it's probably worth
expanding here.

In CVE, we've found that we need the following details in order to be
reasonably certain whether two issues are the same or not:

1) bug type

   DIFFICULTY: terminology like "malformed data structure handling"
   and "memory corruption" do not indicate bug type.  There are many
   ways that input can be "malformed," and more precise terminology is
   desperately needed in this area.  People can contact me off-list
   for thoughts on the topic.

2) affected versions / patch levels

   DIFFICULTY: often not known, especially without coordinated
   disclosure

3) attack vectors (input parameters/fields, programs) *and* affected
   components where the issue is exposed.

   DIFFICULTY: often omitted from reports.  Having a source diff
   doesn't necessarily tell you what the vectors are.  A vendor can
   fix the component and you can't tell if it matches up with the
   vectors listed by the original researcher.

4) For correlation purposes (e.g. figuring out if a vendor fix is for
   vuln X or vuln Y), we find that time of disclosure, researcher
   name, and cross-references are valuable.

   DIFFICULTY: often omitted from reports.

Items 1 through 3, however, are often enough information to construct
an exploit.  This is probably a natural result of having to
distinguish between vulnerabilities.

>Without that level of detail, you end up with this:
>http://www.securityfocus.com/archive/1/443288

Think of the amount of work that must have gone into that analysis,
and you can understand how these essential details can be missed on a
regular basis, in all sorts of disclosures.  This is one example of
how "post-disclosure analysis" is stylistically different from
original research, but has its own technical demands.

- Steve

[1] "Making distinctions between similar-looking vulnerabilities"
    http://seclists.org/bugtraq/2004/Nov/0084.html