[CD] State of CVE Content Decisions

["Steven M. Christey" <coley@linus.mitre.org>]

All,

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):


   ======================================================
   Candidate: CAN-2001-0949
   URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0949
   Proposed: 20020131
   Assigned: 20020131
   Reference: BUGTRAQ:20011204 NMRC Advisory - Multiple Valicert Problems
   Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=100749428517090&w=2
   Reference:
   CONFIRM:http://www.valicert.com/support/security_advisory_eva.html
   [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
   mnemonic.

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.

- Steve





                               Content Decisions

  Index

     * 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

Disclaimer

   Configuration-related CDs are likely to be the most divisive, but
   they are also the least mature, and they are not consistently
   applied.

Abstraction CD's

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

   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

   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
   is used.

   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.

Format CD's

   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
   separately identified.

References

   1. http://cve.mitre.org/board/archives/2001-03/msg00012.html
   2. http://cve.mitre.org/about/terminology.html#Def
   3. http://cve.mitre.org/board/archives/2000-03/msg00009.html