Date: Fri, 5 Nov 2004 15:57:02 -0500 (EST)
From: "Steven M. Christey" <coley@...re.org>
To: bugtraq@...urityfocus.com
Subject: Making distinctions between similar-looking vulnerabilities



This is an obscure topic, but hopefully it's also informative.

Recently on Bugtraq, there was a thread regarding a dhcpd format
string bug that was accidentally linked to an unrelated bug, as begun
by infamous41md [1] and later clarified by Javier Fernandez-Sanguino
[2].  The thread illustrates a relatively common error that sometimes
occurs when reporting or investigating vulnerabilities.  I have seen
several other public cases in which a researcher or other party has
accidentally linked two separate vulnerabilities together and called
them the same bug.  This is an understandable error that even
experienced researchers can make.

These errors can have a more significant impact than causing confusion
to the detail-oriented readers who notice them.  For example, consider
when a vendor reports that they fix problem "X," which is not
conclusively proven to be the same as a separate report for a problem
"Y."  People may believe that the vendor actually fixed problem Y.
(Note to vendors: cross-references are very useful in reducing this
kind of confusion.)

Such errors can make it into vulnerability databases and other
information sources in which accurate information is paramount.

Over the years in CVE, we've found that the following details are
necessary - but not always sufficient - when identifying whether we're
looking at one vulnerability or multiple vulnerabilities:

  - affected product version(s)

  - vulnerability type (which gets problematic because terminology is
    not sufficiently precise these days)

  - affected component (program or feature name)

  - attack vector especially any parameters or arguments
    that serve as the entry points for an exploit

  - affected source code file, function name, and line number

  - specific conditions under which the vulnerability is present
    (e.g. "when feature Z is enabled")

This is obviously from a non-developer perspective.

If there are inconsistencies in any of these details, then you might
be dealing with multiple vulnerabilities.  It is an exercise for the
reader to see which inconsistencies in the DHCP issue(s) were
relevant.

When a vulnerability announcement is not coordinated with the vendor,
or if the vendor provides limited information, then typically you will
only find 2 or 3 of the above details.  This increases the risk of
accidentally merging multiple vulnerabilities together, or even taking
multiple separate reports and treating them as different
vulnerabilities, even if it's really the same issue.  The former is
what happened in the infamous41d report.  The latter typically happens
when the attack vector is reported, but the affected source/functions
are not known, or if the bug type is assumed to be one thing based on
the software's behavior after the attack is executed (null dereference
on long output, anyone?)  This can produce wildly different analyses
by the original researcher versus what the vendor ultimately reports,
which can cause additional confusion if there isn't enough overlap
between the relevant details.

Regular CVE users may wonder why CVE sometimes merges multiple bugs
together into a single CVE item.  There is a wide variety in the
amount of details that are provided for different vulnerabilities, and
we strive for consistency across the space of all vulnerability
reports.  We've developed criteria ("content decisions") that rely
most heavily on using the affected product version and the bug type,
which are the most frequently reported details that can be used to
distinguish between vulnerabilities.  We use what details are
available and don't try to make any further distinctions.  Thus you
may wind up with multiple bugs of the same type being merged into the
same CVE identifier.  Other vulnerability information sources, such as
vulnerability databases, may use different criteria that will make
more fine-grained distinctions (i.e. "more" vulnerabilities than CVE)
or more abstract ones (i.e. "less" vulnerabilities than CVE).


- Steve


References:

[1] BUGTRAQ:20041026 debian dhcpd, old format string bug
    Author: infamous41md
    URL:http://marc.theaimsgroup.com/?l=bugtraq&m=109887434017870&w=2

[2] BUGTRAQ:20041102 Re: debian dhcpd, old format string bug
    Author: Javier Fernandez-Sanguino
    URL:http://marc.theaimsgroup.com/?l=bugtraq&m=109943160319310&w=2

Powered by blists - more mailing lists