[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TECH] Duplicate candidates - which one should be preferred?

Two issues to address:

1. As a matter of convenience and record, I (acting on the behalf of ISS)
have been sending MITRE an encrypted copy of our advisory draft for
candidate assignment for well over a year. I find it much easier and less
error prone than assuming that the issue is new. The entire exchange is
handled in ciphertext, and MITRE destroys all records of the conversation
after it is has completed the assignment.

There is a very real concern at ISS about the 'leaking' of pre-release
material by a third party. Should this occur, I have no doubt that my a$$
would be mighty sore. MITRE provided ISS with an official and military-grade
declaration on what they would and would not do with confidential and
private content, including issues of confidentiality, information handling,
and immediate disposal after candidate assignment.

2. With regards to which candidate to promote, ISS X-Force uses a similar
protocol to select between duplicates. If either issue is linked to a
product or to CVE (i.e., is more "official"), then we promote it. Otherwise,
we promote the first-entered issue. In either case, we sync the references
and information to the promoted issue, and NEVER delete the obsoleted issue.
These guidelines have worked for us more times than I'd like to admit. :-)


Andre Frech
X-Force Security Researcher
Internet Security Systems (ISS)
6303 Barfield Road
Atlanta, Georgia 30328-4233

Internet Security Systems -- The Power to Protect

-----Original Message-----
From: Steven M. Christey [mailto:coley@linus.mitre.org]
Sent: Tuesday, February 27, 2001 11:36 PM
To: cve-editorial-board-list@lists.mitre.org
Subject: [TECH] Duplicate candidates - which one should be preferred?


If you've been reading Bugtraq, then you may have noticed that @stake
and Microsoft recently published advisories regarding a vCard buffer
overflow (MS:MS01-012), which was given a candidate number
CAN-2001-0145, which was included in both the @stake and Microsoft
advisories.  However, it turns out that this issue was originally
discovered and posted in 2000; it was assigned CAN-2000-0756, and
proposed to the Editorial Board in September.  Thanks to Andre Frech
for bringing this to my attention while I've been on travel.

The information on the affected candidates is included at the end of
this message.

So, now we have 2 publicized candidates that describe the same
vulnerability.  This was going to be a topic of discussion at the
Board meeting, but it's effectively been publicized this week, so I
thought I'd start early.

The problem of duplicate candidates was expected to increase as
candidates were introduced earlier and earlier in the vulnerability
cycle.  Unfortunately, this has proven true.  Duplication becomes
especially risky as vendors and researchers exchange candidate numbers
without including MITRE as a third party.  I've been referring to this
as "blind candidate reservation."  Despite the increased likelihood of
duplicate candidates, the benefit of blind candidate reservation is
that there is one less organization to accidentally leak information
before it is publicized (i.e. MITRE); the candidate review process can
resolve the duplication.

When duplicate candidates arise, we must ultimately decide which
candidate should be promoted to an entry.  In the August 2000 meeting,
the Board said that MITRE could decide this issue themselves.
However, I'd like to consult you again, now that we have a more
concrete example to work with.  (A similar issue arose in November
when ISS and NAI discovered extremely similar vulnerabilities as
documented in CAN-2000-0885 and CAN-2000-0817, but that situation is
more complex, since it also involves content decisions).

Following are the guidelines that I've been considering for handling

- promote the more "official" candidate to an entry (e.g. if it comes
  from a CERT advisory or a vendor advisory)

- if all else is equal, then promote the candidate that was first made

In this case, since CAN-2001-0145 came from Microsoft, i.e. an
official source, then it might be preferred over CAN-2000-0756, even
though CAN-2000-0756 was publicized in September 2000.  The argument
for preferring CAN-2000-0756 would be that it's been around for a
longer time.

It's possible that Microsoft could change their reference back to
CAN-2000-0756.  However, the bulletins have probably reached a wider
audience than CAN-2000-0756 itself has (since it probably hasn't made
it into many tools, and it wasn't included in the original Bugtraq
post).  So, CAN-2001-0145 is perhaps better known than CAN-2000-0756.

The guidelines suggest that CAN-2001-0145 would be promoted instead of
CAN-2000-0756.  So, is that reasonable?

- Steve

Candidate: CAN-2000-0756
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0756
Proposed: 20000921
Assigned: 20000919
Category: SF
Reference: BUGTRAQ:20000831 vCard DoS on Outlook 2000
Reference: BID:1633
Reference: URL:http://www.securityfocus.com/bid/1633

Microsoft Outlook 2000 does not properly process long or malformed
fields in vCard (.vcf) files, which allows attackers to cause a denial
of service.

INFERRED ACTION: CAN-2000-0756 SMC_REVIEW (3 accept, 2 review)

Current Votes:
   ACCEPT(2) Cole, Levy
   MODIFY(1) LeBlanc
   REVIEWING(2) Christey, Wall

Voter Comments:
 LeBlanc> - if a KB article, bulletin, or patch can be found, then
   I'll ACCEPT
 Christey> This is the same as MS:MS01-012 (CAN-2001-0145)
   See the Bugtraq post by Joel Moses:

   As of this writing, it is not certain which candidate
   should be preferred: the candidate that has been publicly
   known longer (i.e. CAN-2000-0756), or the more "official"
   candidate, which has probably been publicized more (i.e.

Candidate: CAN-2001-0145
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0145
Assigned: 20010210
Category: SF/CF/MP/SA/AN/unknown
Reference: MS:MS01-012
Reference: ATSTAKE:A022301-1
Reference: URL:http://www.atstake.com/research/advisories/2001/a022301-1.txt

Buffer overflow in VCard handler in Outlook 2000 and 98, and Outlook
Express 5.x, allows an attacker to execute arbitrary commands via a
malformed vCard birthday field.

INFERRED ACTION: CAN-2001-0145 ASSIGNED (Assigned 20010210)

Current Votes:
   REVIEWING(1) Christey

Voter Comments:
 Christey> In a post to Bugtraq, Joel Moses notes that this is a
   duplicate of CAN-2000-0756:

   As of this writing, it is not certain which candidate
   should be preferred: the candidate that has been publicly
   known longer (i.e. CAN-2000-0756), or the more "official"
   candidate, which has probably been publicized more (i.e.

Page Last Updated or Reviewed: May 22, 2007