[CD] State of CVE Content Decisions
This is a quick note, as I'm heavily occupied with other things such
as preparing a new CVE version.
1) Dave Mann and Pascal Meunier have separately brought up the old
"dot notation" discussion. We haven't forgotten about this, but in
the scheme of things, it's a lower priority than, say, catching up
on the backlog of legacy and new candidates.
When an abstraction CD causes several issues to be MERGED into a
single candidate, the description gives a "bulleted" list of the
specific "instances" of that candidate (when those instances are
known; sometimes a source says "multiple buffer overflows" but
doesn't give more details.) This is the precursor to formalizing
dot notation. I'm playing around with a way to link SPLIT issues;
I'm not sure whether this should be done via references or a
separate "CD" attribute.
Here's an example (which should be familiar to those who were
interested in last week's SNMP/abstraction thread):
Reference: BUGTRAQ:20011204 NMRC Advisory - Multiple Valicert Problems
[Numerous references removed for brevity]
Buffer overflows in forms.exe CGI program in ValiCert Enterprise
Validation Authority (EVA) Administration Server 3.3 through 4.2.1
allows remote attackers to execute arbitrary code via long arguments
to the parameters (1) Mode, (2) Certificate_File, (3) useExpiredCRLs,
(4) listenLength, (5) maxThread, (6) maxConnPerSite, (7) maxMsgLen,
(8) exitTime, (9) blockTime, (10) nextUpdatePeriod, (11) buildLocal,
(12) maxOCSPValidityPeriod, (13) extension, and (14) a particular
combination of parameters associated with private key generation that
form a string of a certain length.
We've been doing this for about 5 months now, but I suppose it
would only be apparent to voting members (and this probably answers
some lingering questions in some voters' minds ;-)
2) Over time, several Board members have asked where the content
decisions are located, and where they can get the most recent copy.
The fact is that only some of the CDs are documented well enough
for public consumption. In some cases, such as CD:CF-PASS (default
passwords), there's a *label* and a 1-line writeup for the CD, but
that's about it. For other CDs like SF-LOC and SF-EXEC, we're
considering changing the names entirely, to something more
3) The CD documentation has been improved significantly over the past
few months, as I've been developing training and reference
materials for the content and CNAs. Only the most significant CDs
have any reasonable documentation. However, some of them are
politically incorrect - they include informal commentary regarding
specific issues, and this needs to be cleaned up before publication
outside of MITRE's CVE team.
4) My plan is to first post the CDs to the Editorial Board mailing
list, along with a notion of how "debatable" they are, then more
deliberately integrate them into the CVE web site and the CVE data.
This was on my to-do list - *after* the next CVE version. CD:VAGUE
keeps cropping up so many times, and it's never been discussed
before (unlike most other CDs), so I introduced it "early."
5) MITRE and the charter Editorial Board members learned a hard lesson
in summer 1999: we have to be careful about having *too much*
discussion and too many topics happening all at once. Right now,
CD:VAGUE is getting some attention, and I will be making an
announcement later today, which might trigger some additional
commentary. So I think it would be better to delay posting the
details for other CDs until next week.
6) For those who can't wait any longer, below is a summary of the CDs
we're actively using. More detailed explanation will come sometime
after I get out the next CVE version and round of new candidates.
Note: this is a plaintext version of an HTML document; there are
implicit references to links or other web pages that I don't have
the time to clean up at the moment.
* Abstraction CD's - SF-LOC, SF-EXEC, SF-CODEBASE, CF-DEFAULT,
CF-PASS, REDISCOVERY, CF
* Inclusion CD's - DEFINITION, VAGUE, EX-BETA, EX-CLIENT-DOS,
DESIGN-WEAK-ENCRYPTION, DESIGN-REAL-PATH, EX-ONLINE-SVC
Configuration-related CDs are likely to be the most divisive, but
they are also the least mature, and they are not consistently
An Abstraction CD specifies what level of abstraction (level of
detail) a issue (or multiple related issues) should be described
at, e.g. whether a particular issue should be given 1 candidate or
5 candidates. The basic problem is: different people have different
opinions for how to distinguish between issues. Rationales for
some abstraction CD's are on this Editorial Board post
SF-LOC: Multiple vulnerabilities in the same executable.
SF-EXEC: The same apparent vulnerability in multiple executables of
the same product or package, or a library that is used by many
SF-CODEBASE: The same apparent vulnerability in a codebase that is
used by many vendors (major example: most Unix/Linux code)
CF-DEFAULT: [**NOTE: THIS IS APPLIED INCONSISTENTLY**] Create a
separate entry for a default configuration that is specific to a
product and introduces a vulnerability or exposure.
CF-PASS: [**NOTE: THIS IS APPLIED INCONSISTENTLY**] This deals with
default passwords. The current approach is to create candidates for
products that ship with default passwords. This has been hotly
debated; some Board members argue that (1) there's a large number
of default passwords, which could "explode" the size of CVE, and
(2) vulnerability assessment tools may have large collections of
passwords in which it can't be determined whether the password was
a default, or guessable.
REDISCOVERY: (This is an experimental CD). An issue in a particular
codebase that is rediscovered in a separate vendor's product at a
much later time (1 year or more) may be assigned a different CVE.
CF: There are major abstraction issues for managing configuration
problems. If a configuration issue is specific to a particular
product and there is little variation across different deployments
of that product, then it can be included.
Inclusion CD's specifies whether certain types of vulnerabilities or
exposures should go into CVE.
DEFINITION: If an issue meets the definition of a vulnerability or
exposure, then it may be included in CVE (pending the application
of INCLUSION CD's).
VAGUE: If a vendor acknowledges or publicizes an issue and says
it's security related, but the vendor is vague about the details,
it should still be included.
EX-BETA: Exclude problems in software that is beta or alpha code
unless that version is in wide use. (Example: ICQ is in "permanent
beta" and it's in wide use.) Not finalized; create a CAN anyway.
Rationale is here.
EX-CLIENT-DOS: Exclude client-side DoS that only affects
convenience. Not finalized; create a CAN anyway.
DESIGN-WEAK-ENCRYPTION: Include problems in which weak encryption
DESIGN-REAL-PATH: A configuration or design error that leaks
information such as the full pathname for a server is an exposure,
so it should be included in CVE.
EX-ONLINE-SVC: Exclude problems in online services or ASP's where
the problem is specific to that service and does not require
additional software by the client. Examples are free mail services
(e.g. hotmail), online banking and shopping, etc. NOTE: A problem
that's in a separately downloaded client that the vendor can fix at
the server is not EX-ONLINE-SVC. Often such problems can still be
exploited in direct client-to-client communications.
DOT: Use "Dot notation" in the CVE description if the entry could
be at a higher level of abstraction than "expected" and/or an
abstraction CD recommends merging multiple issues that can be