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

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

All,

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

- 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
  public

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
Final-Decision:
Interim-Decision:
Modified:
Proposed: 20000921
Assigned: 20000919
Category: SF
Reference: BUGTRAQ:20000831 vCard DoS on Outlook 2000
Reference: URL:http://www.securityfocus.com/templates/archive.pike?list=1&msg=Springmail.105.967737080.0.16997300@www.springmail.com
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:
   http://marc.theaimsgroup.com/?l=bugtraq&m=98322714210100&w=2

   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.
   CAN-2001-0145).


======================================================
Candidate: CAN-2001-0145
URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0145
Final-Decision:
Interim-Decision:
Modified:
Proposed:
Assigned: 20010210
Category: SF/CF/MP/SA/AN/unknown
Reference: MS:MS01-012
Reference: URL:http://www.microsoft.com/technet/security/bulletin/ms01-012.asp
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:
   http://marc.theaimsgroup.com/?l=bugtraq&m=98322714210100&w=2

   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.
   CAN-2001-0145).