full-disclosure - RE: The new Microsoft math: 1 patch for 14 vulnerabilities, MS04-011

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]

Message-ID: <200404152305.i3FN5TWJ023519@linus.mitre.org>
From: coley at mitre.org (Steven M. Christey)
Subject: RE: The new Microsoft math:  1 patch for 14 vulnerabilities, MS04-011

> Well, which is it? 3, 21, 20, "over 30", "at least 20"?

As we've learned in CVE, there are legitimate reasons for any of these
numbers, such as:

  1) The "role" of the person viewing the numbers.  For example, an
     IDS person may care about each individual attack vector; a
     sysadmin may only care about the number of patches to apply; a
     vendor may want to reduce the "information overload" for
     customers; a detail-oriented vulnerability researcher may care
     about the number of underlying issues, in which a single program
     error could have many attack vectors, etc.

  2) The amount of detail available for the issue(s).  This isn't
     necessarily an open- vs. closed-source thing, either; for
     example, the just-announced neon vulnerability (CAN-2004-0179)
     has "various format string vulnerabilities," but even if you put
     in the effort to dig up the source and do a diff, how many of
     those bugs are actually reachable/controllable by an attacker?
     And PROTOS-style vulnerability analyses are often so effective
     that they have the interesting dichotomy of being simultaneously
     replete and dereft of details (e.g. here are 2000 test cases, but
     which vendor was affected by test case number 472?)

  3) The maturity of the vulnerability information.  The understanding
     of a vulnerability can change over time, and new information can
     result in a re-assessment (and perhaps re-counting) of the
     vulnerability/ies.

  4) Something a little more subtle: the intention/programming style
     of the software developer.  Example: suppose you have an
     application that manages files, and there is a development
     "policy" of trimming long file names.  It forgets to do this in
     one particular routine in the code, which leads to buffer
     overflows in two lower-level functions that assume that the
     filename has been trimmed.  Is that one vulnerability or two?
     (We're excluding the question of whether the underlying design
     choices count as vulnerabilities themselves.)

There are likely others that don't immediately pop into mind.

At this point in time, the best way to "count" vulnerabilities is to
look within the advisories and use a sufficiently consistent mechanism
to NORMALIZE how many vulnerabilities there are.  That's one of our
main goals in CVE, as reflected in its content decisions, but most
"vulnerability databases" (or similar resources) have their own
consistency rules.


- Steve