Dot Notation Proposal WAS: Exploding CVE entries

[Dave Mann <damann@mitre.org>]

Pascal Meunier wrote:
> So what do we do for the codebase issue?  Simple:  in a single CVE entry,
> enumerate all the OSes or distributions with a problem that fits the
> observables in the description, being understood that there is a different
> instance of the vulnerability in each -- in effect a sub-enumeration of
> vulnerabilities.  If it is acceptable for passwords, then it should be
> acceptable accross the entire CVE.


Allow us to suggest an idea that we've been kicking around
here at MITRE for a few weeks.  I alluded to this idea with
my analogy a week or so ago to the card catalog in the library.
Recall, the observation there was that card catalogs operate
at (at least) 2 levels of abstraction in terms of enumeration.
For example, the card catalog may have a dozen cards with the
title "Moby Dick".  But, each card may represent a different edition.
We might call the levels of abstraction "Same Title" and
"Same Edition".

Our suggestion for resolving the "Same Attack" vs "Same Codebase"
issue (and other issues related to level of abstraction) is to move
to a 2 tiered naming scheme.  We suggest reserving the now
standard CVE nomenclature for vulnerabilities that are essentially
the same at the same attack (or some equivalent level of abstraction).
This nomenclature could then be extended to cover each particular
instance of the base vulnerability by appending a new number with a dot.

For example, citing the Ping of Death example that Pascal mentioned,
we would have:

CVE-1999-0128  <--- NOTE! NO DOT!
Reference: XF:ping-death
Reference: CERT:CA-96.26.ping
Description: Oversized ICMP ping packets can result in a denial of
service, aka Ping o' Death.

CVE-1999-0128.1
Description: The occurrence of CVE-1999-0128 in
Digital Unix 3.0x, 3.2x, 4.0, 4.0a and products based on these

CVE-1999-0128.2
Description: The occurrence of CVE-1999-0128 in
FreeBSD v prior to 2.1.6

CVE-1999-0128.3
Description: The occurrence of CVE-1999-0128 in
HPUX 9.x, 10.00-10.20,

CVE-1999-0128.4
Description: The occurrence of CVE-1999-0128 in
AIX 3.2, 4.1, 4.2

CVE-1999-0128.5
Description: The occurrence of CVE-1999-0128 in
Linux kernels prior to 2.0.27

CVE-1999-0128.6
Description: The occurrence of CVE-1999-0128 in
OSF/1 prior to R1.3.3

CVE-1999-0128.7
Description: The occurrence of CVE-1999-0128 in
SCO OpenServer 5.0.0, 5.0.2;
SCO Internet FastStart 1.0.0, 1.1.0;
SCO Open Desktop 3.0;  or
SCO TCP/IP 1.2.1 on SCO Unix System V/386 Release 3.2 Version 4.2

CVE-1999-0128.8
Description: The occurrence of CVE-1999-0128 in
Solaris, unpatched versions prior to 5.51

NOTE 1:  There are significant implementation issues that we must
consider beyond the logical issues.  For example, do we want
to have separate CVE entries for each (at differing levels of
abstraction as suggested above) or do we want to only
maintain one master entry for each vulnerability with specific
instances mentioned in the description? For instance we could
say:

CVE-1999-0128:
Ping of Death, affecting [1]Solaris, [2]blah blah, [3]blah blah, etc.

So CVE-1999-0128.1 would translate into "Ping of Death" for Solaris.

The logical result is the same despite the implementation differences.

NOTE 2: This 2 tiered approach allows someone using the CVE to decide
between accuracy at the higher level (at the cost of reduced precision),
or precision at the lower level (at the risk of being inaccurate).

NOTE 3: This approach could be useful in other cases as well, e.g. the
default password debate or other later discussions which will deal
with other high cardinality problems.

NOTE 4: This approach would allow us to gain faster agreement at the
higher level of abstraction now, while allowing us to augment CVE
as we learn more about dealing with vulnerabilities at the lower
levels of abstraction.  Remember, we would like to move forward
with a fully public version of the CVE by the end of the summer!!

We have resisted making this suggestion until now for fear of
needlessly complicating the name space.  And clearly, this opens a Pandora's
Box. For instance, this raises the issue of introducing multiple
levels of dots which is taking us down the primrose path of a
hierarchical classification -- a path we do not want the CVE to
go down at this point in time.   However, I think the recent
discussions have demonstrated the real need to manage vulnerability
information at these 2 particular levels of abstraction.


Dave Mann & Steve Christey