Re: Misinformation in Security Advisories (ASN.1)

["Steven M. Christey" <coley () mitre org>]

Based on our experiences in CVE, many advisories frequently have (a)
incomplete, (b) inaccurate, or (c) inconsistent information.

To use the eEye / ASN.1 issue as a *single* example of many that I run
across:

  - eEye published 2 advisories that each said there were "multiple"
    integer overflows

  - Microsoft advisory MS04-007 says that there is "a" security
    vulnerability, which could be interpreted as saying there is one
    bug

  - Microsoft's advisory also calls it a "buffer overflow" and there
    is no mention of "integer overflow."

One might reasonably ask:

  - did Microsoft fix all 4 (or more) bugs?  Or, since they fixed a
    "buffer overflow," did they fix something completely different?

    (an email to Microsoft confirmed that in fact the 4+ bugs were
    fixed in MS04-007; but now you must decide if you trust *my*
    claim).


In this case, since we had a well-regarded party (eEye) release
vulnerability information on the same day as a Microsoft advisory that
credited them, we might be able to "reasonably assume" that both
parties are talking about the same issue/issues.  One might resolve
the discrepancy terminology by recognizing that terminology in
vulnerability research is a moving target.  Currently, it lacks the
extra precision that is required to properly distinguish between
closely related bug types.  For example, I think the term "buffer
overflow" these days is applied to somewhere between 5 and 10 "bug
types" or attack vectors; it's not just "classic buffer overflow"
anymore.  "Directory traversal" is another example of an
overloaded/imprecise term.

Regarding the assessment of the "exploitability" of an issue, as
discussed by Ivan Arce: an approach that is chosen by some vendors is
"if it's a buffer overflow, then we treat it as if it's exploitable."

A final note on buffer overflows and security advisories.  I've seen a
number of advisories that *claim* a buffer overflow because the
researcher could send a long input to cause a process to be crashed.
But a null dereference also causes a crash.  Some non-zero number of
claimed overflows may really be null dereferences or other such
problems, especially as programmers learn to identify "invalid input"
but forget to properly handle the resulting error condition.

- Steve