Exploding CVE entries

[Pascal Meunier <pascalm@cup.hp.com>]

Please bear with me, I think I have an idea that could simplify our lives
(or did I just now understand what others have been thinking about?).  I
think it is appropriate to use formulas that can accurately represent a
space of vulnerability instances.  The obvious example is passwords:  if a
password is in a current dictionary, then it's a vulnerable password.
Here, one leverages dictionaries as a sub-enumeration of the vulnerability
entry.  The result is a CVE entry that can be unambiguously exploded to the
lowest level of instantiation, but without any classification of
vulnerabilities being performed by the CVE itself.  I am less enthusiastic
about the more encompassing but fuzzier "guessable", but voted ACCEPT
because the task of defining "guessable passwords" has already been
undertaken so many times that it is almost unambiguous, and can be
leveraged by the CVE.

In the same manner, I think that it is unnecessary to have an entry for
each system-critical file in an OS if a list of those is available
elsewhere (maybe a reference to the list would be a good idea).  The idea
is simply to use a compact notation that is 1) unambiguous and 2) involves
no classification or abstraction on the part of the CVE.  I think that
using unambiguous compact notations (sub-enumerations) would be a practical
and defensible way to reduce the number of entries and thus the work
involved, and increase the managability of the CVE.

The reason that this can't work with codebases is that the generalization
of codebases (e.g., "Unix-type systems") is an ambiguous abstraction -- is
BeOS "Unix-type"?  What about MacOS X (not the server version already
released, but the consumer version due this fall with the MacOS
interface?).  Moreover each codebase is under the control of a different
entity which can change the code without notice, and may already have done
so.  Linux? erh, Yellow-dog, LinuxPPC, mkLinux, RedHat, SUSE, etc... may
all have different code.  It follows that codebases are also ambiguous
versus time and software versions.  Therefore each instance of a
vulnerability in the code controlled by each entity must be listed
separately with the version number in which it was observed.

According to this I should object to the CVE entry on guessable passwords
in "Unix".  The reason I didn't is that the password problem happens in all
codebases and all operating systems, therefore the ambiguity is resolved by
the ubiquity of the vulnerability.  It would have been perfectly acceptable
to me to have only one CVE entry for guessable passwords, being understood
that there isn't just one instance of the vulnerability.

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.

Pascal