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
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.
- 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
- 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
- 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."