[TECH] Handling "reservation duplicate" candidates

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

All,

Recently, we had a situation in which a CVE candidate was reserved by
a CNA, and accidentally assigned to an issue when a candidate was
already available, then published.  We therefore have a situation in
which a candidate needs to be REJECTED as a duplicate, even before it
has been proposed to the CVE Editorial Board.

This type of issue is likely to happen more frequently as more and
more people reserve candidates.

I will use specific examples here, but there are others.

So far, I've identified the following scenarios in which "reservation
duplicates" may occur:

1) DUPLICATE OF PREVIOUSLY DISCLOSED VULNERABILITY

  An entity reserves and publishes a candidate for an issue that was
  previously disclosed and assigned a CVE ID.

  The entity could be a researcher, coordinator, Candidate Numbering
  Authority (CNA), or other party; any of these parties could
  double-check for duplicates.

  A rough example of this is CAN-2002-0680, a directory traversal
  issue in GoAhead Web Server 2.1 via encoded / characters.  I
  reserved this for Matt Moore, but I did not search CVE for previous
  reports, where there was a "clean" directory traversal issue in the
  same version of GoAhead, as reported in CAN-2001-0228.  (There are
  slightly different attacks, and the vendor was unresponsive, so
  there was insufficient information to know whether this was really a
  distinct issue or not; however, I should have caught the potential
  duplicate and investigated *before* assigning the new candidate).

2) CONTENT DECISION ERROR

  A CNA applies CVE content decisions inappropriately, and decides to
  produce a separate candidate when the original candidate should have
  been used.

  This recently happened with the gopher buffer overflow in Microsoft
  products (CAN-2002-0371 and CAN-2002-0646).  Microsoft had released
  2 separate bulletins for separate packages, so it made sense to them
  to create two separate candidates, one for each bulletin.  This
  would be reasonable to many people.  However, this conflicts with
  the CD:SF-CODEBASE content decision.  This emphasizes the need for
  "CNA training" with respect to content decisions, and of course
  requires that CDs need to be reasonably easy to use.

3) MULTIPLE INDEPENDENT ASSIGNMENTS

  This can happen when CNA's and researchers do not share the same
  candidate number, and multiple candidates are published at the same
  time, for the same issue.  This hasn't happened yet, but it probably
  will sometime, as more and more parties begin to reserve numbers
  from sources other than MITRE.

  There was a very close call, however, when ISS reserved a candidate
  for the Apache chunked encoding overflow.  Red Hat had already
  reserved CAN-2002-0392 for the issue, but I was not fully aware of
  the details at the time; when ISS came to me for a number for their
  advisory, I did not recognize that the report was the same, and I
  reserved CAN-2002-0625 for ISS to use.  However, as we know, the
  public release of this vulnerability was not fully coordinated.  In
  this case, I was fortunate enough to catch the duplicate
  CAN-2002-0625 before it was even placed on the CVE web site, and ISS
  did not include it in their advisory.  Since CAN-2002-0625 was never
  public, I silently "deleted" it, just like I do with duplicate
  candidates that are caught during the MITRE's internal refinement
  process, before they are ever published or proposed.

There can be combinations of the above situations.  For example, there
can be partial duplicates of previously disclosed vulnerabilities,
which gets into content decision issues:

  CAN-2001-0145 (@stake's discovery of a vCard overflow in a
  particular field) and CAN-2000-0756 (the original discovery of the
  vCard overflow, which reported multiple fields but only claimed a
  DoS).  In this case, there are also abstraction differences between
  CAN-2000-0756 and CAN-2001-0145; and the "more authoritative"
  candidate (CAN-2001-0145) doesn't have the same amount of details as
  the "more comprehensive" CAN-2000-0756.

There can be other issues, such as abstraction errors in which a
single candidate is reserved for multiple issues that really should
get separate candidates.  This recently happened with CAN-2002-1165
(Sendmail smrsh issues), in which iDEFENSE reserved a candidate for
one issue, found a variant and got it fixed before publishing, and
released both issues in the advisory with the single candidate.
However, the types of vulnerabilities were different enough that
CD:SF-LOC suggests that they should have been SPLIT.


Reducing the Likelihood of Reservation Duplicates
-------------------------------------------------

While reservation duplicates probably cannot be eliminated, here are
some ways to reduce the likelihood that duplicate candidates will be
reerved and published for the same issue:

1) Coordinated disclosure between the vendor, researcher, and other
   involved parties.  This is not always possible when vendors are
   unresponsive, or if researchers release vulnerabilities before the
   vendor has a chance to fix the issue.

2) All "CVE-speaking" parties need to exhange candidate numbers within
   the process.  This is especially important for multi-vendor issues,
   or if multiple researchers discover the same issue at the same
   time.

3) CNAs need to become familiar with CVE content decisions, and
   consult with MITRE in any cases where there is uncertainty.



Handling Reservation Duplicates Upon Publication
------------------------------------------------

Here's my first cut at how to handle reservation duplicates when they
are published:

1) If one of the identifiers is a CVE-xxxx entry, then it will be
   preferred.

2) If they are both candidates, then:

   - if there are abstraction errors, then the candidate that is more
     consistent with content decisions will be preferred.

   - otherwise, the more authoritative candidate will be preferred.

   - otherwise, the candidate that was first released will be
     preferred.


If a reservation duplicate has not been proposed to the Board yet,
then the following will happen:

1) The description of the reservation duplicate will be modified to
   emphasize that it is a duplicate; all references to the specific
   vulnerability will be removed, to reduce the risk of misuse.

2) The reservation duplicate's description will point to the correct
   CVE identifier.

3) The reservation duplicate will be proposed to the Editorial Board
   (for formal tracking purposes); voting Board members will simply
   REJECT it.


So, for the gopher buffer overflow, I am going to do this:

1) REJECT CAN-2002-0646 (since it was released later than the other
   candidate, the other candidate has the right abstraction level, and
   they are equally authoritative)

   Since this hasn't been proposed to the Board yet, the rejection
   will happent his way:

    - change the "blank" description to say that it is going to be
      REJECTED in favor of CAN-2002-0371.

    - propose the candidate to the Board, for the specific purpose of
      REJECTING it in the voting record

2) I will then modify CAN-2002-0371 (the older candidate, for
   ISA/Proxy server) by adding the later MS02-047 bulletin as a
   reference (the description already mentions IE).


Thanks to Andre Frech for inquiring about the gopher refinement
duplicates, which forced me to get my act together to resolve this
issue and discuss the implications with the Board :-)

- Steve