|
|
|
[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 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? 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=Springmai l.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).
|
||||
