[Date Prev][Date Next
][Thread Prev][Thread Next
[TECH] Handling "reservation duplicate" candidates
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
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
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
1) If one of the identifiers is a CVE-xxxx entry, then it will be
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
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
3) The reservation duplicate will be proposed to the Editorial Board
(for formal tracking purposes); voting Board members will simply
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 :-)