[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Level of Abstraction Issue: Similar Applications, "Same" Vulnerability


Gene Spafford advocated using a lower level of abstraction than the
current CVE content decisions for similar applications exhibiting "the
same" vulnerability.

The CVE content decision under question can be summarized as: "Same
attack, same software flaw = same vulnerability."  Let's just call
this the "Same Attack" level.

Gene is advocating what I'll uncreatively refer to as "Same attack,
same software flaw, same code base = same vulnerability."  Let's call
this the "Same Codebase" level:

>From my point of view, if the software involved harkens from a
>different code base, then it merits a different listing.  Thus, a
>buffer overflow in mail servers should take multiple listings if it
>affects different servers.
>
>The attack may be the same.   The underlying software flaw is the 
>same.  But the CVE should reflect the configuration that is 
>vulnerable, and that may require multiple entries.

While certainly this distinction makes sense for some uses of
vulnerability data, I have some concerns about a Same Codebase level.

Pros:
  - appropriate for the analysis of software engineering mistakes,
    and the education of programmers.  Allows one to see how many
    different developers screw up the same thing.
  - an "official" distinction in the CVE could in some fashion support
    the long-term goals of security-conscious programming.
  - some CVE "end users" (ie sysadmins) can look up the CVE number for
    vulnerabilities that affect the applications they are running on
    their systems.

Cons:
  - lower level than necessary for IDSes; since the attack is the
    same, the signature is the same (IDS people, please don't slam me
    for overgeneralizing ;-)
  - lower level than necessary for scanners; since the attack is the
    same, the test is the same
  - increases the raw number of vulnerabilities that a CVE "end
    user" (sysadmin) must consider fixing/verifying (whether reported
    by IDSes or network scanners, or as generated by a CVE-savvy
    vulnerability database)
  - in some cases, it may not be easy to know if 2 applications
    have the same "code base" or not, without interacting more
    closely with the app. vendor.  Consider a Sendmail bug that
    affects multiple OSes; did each OS vendor make the same mistake
    when tweaking the application for their OS, or was the bug from
    Allman's original code?  We can only make this distinction by
    analyzing the source code and/or depending on vendors to provide
    us with such information, which can introduce (a) delay while
    waiting for vendor response (CERT model), or (b) error if we
    make guesses without the vendor's response, which might require
    some "renumbering" later on (ie splits or merges)


I believe that the Same Attack approach has more practical, everyday
usage than Spaf's Same Codebase perspective, since (a) it's at the
level that IDSes and scanners would operate at; and (b) it's at the
level that (in my experience) sysadmins like to see it at, especially
as they pore through the voluminous results of security tools.  I
believe that as long as we make sure that the description identifies
all affected applications, then the current CVE content decision
remains the most appropriate for the community at large, especially
when considering the "end users."

Comments?

- Steve
Page Last Updated or Reviewed: May 22, 2007