RE: [TECH] High-level candidates for recent SNMP problems

["David LeBlanc" <dleblanc@microsoft.com>]

You didn't say I couldn't bring up old arguments, so... >8-)

Unless you're willing to type up CANs for each and every little variant
that gets discovered, then (IMVHO - opposite of IMNSHO) I would try not
to establish a low level of abstraction. It's going to get really,
really ugly. I well understand the academic arguments, but there's a
pragmatic concern - I don't think we want to double the size of the CVE
database (oops, list pretending not to be a database, sorry) just to
cover a bazillion variants of this particular bug. Even getting it down
to codebase is going to be very, very difficult.

IMHO, I'd put the 2 CANs you've got through and call it a day. You've
got better things to do with your time than try and sort all this out.

My $0.02, YMMV, do what you like from here.

> -----Original Message-----
> From: Steven M. Christey [mailto:coley@linus.mitre.org] 
> Sent: Tuesday, February 12, 2002 2:00 PM
> To: cve-editorial-board-list@lists.mitre.org
> Subject: [TECH] High-level candidates for recent SNMP problems
> 
> 
> All,
> 
> The recently announced SNMP problems pose a special challenge 
> for using CVE candidates.  The basic problem is that the CVE 
> content decisions dictate that we should provide different 
> candidates for each implementation that is affected by the 
> PROTOS suite (Jim Magdych, this probably isn't a good time to 
> bring up old arguments please ;-)
> 
> Despite the number and complexity of the issues, the CVE 
> content decisions are pretty clear on how candidates should 
> be assigned:
> 
> - separate candidates for each affected codebase (CD:SF-CODEBASE)
> 
> - separate candidates for each type of problem within the same
>   codebase (CD:SF-LOC) and version
> 
> However, there is insufficient information at this time to 
> assign the proper number of candidates.  So, we currently 
> only have a few candidates, and they are at a level of 
> abstraction that is higher than they "should" be (relative to 
> content decisions).
> 
> The codebase issue is a difficult one, but the general 
> approach will probably be to distinguish by vendor, unless 
> there is clear proof that multiple vendors use the same codebase.
> 
> Below is the current list of candidates that CERT/CC has 
> assigned and publicized.  They will be on the CVE web site 
> within an hour.  They will likely change rapidly and without notice.
> 
> As we better understand the specifics, I will be assigning 
> separate candidates to the more explicitly identified issues. 
>  If other general "classes" of vulnerabilities are also 
> discovered, it is likely that other high-level candidates 
> will be created for that, too.
> 
> This is a prime example of how CVE content decisions are 
> dependent on the amount of available information.  I've been 
> able to remove the dependencies of content decisions on 
> certain types of information, but there is still a reliance 
> on problem types, affected codebases, and affected versions.  
> I alluded to this difficulty in a post to Bugtraq a week or two ago.
> 
> - Steve
> 
> 
> ======================================================
> Candidate: CAN-2002-0012
> URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012
> Final-Decision:
> Interim-Decision:
> Modified:
> Proposed:
> Assigned: 20020110
> Category: SF
> Reference: ISS:20020212 PROTOS Remote SNMP Attack Tool
> Reference: URL:http://www.iss.net/security_center/alerts/advise110.php
> Reference: CERT:CA-2002-03
> Reference: URL:http://www.cert.org/advisories/CA-2002-03.html
> Reference: CERT-VN:VU#107186
> Reference: URL:http://www.kb.cert.org/vuls/id/107186
> 
> Vulnerabilities in a large number of SNMP implementations 
> allow remote attackers to cause a denial of service or gain 
> privileges via SNMPv1 trap handling, as demonstrated by the 
> PROTOS c06-SNMPv1 test suite.  NOTE: It is highly likely that 
> this candidate will be SPLIT into multiple candidates, one or 
> more for each vendor.  This and other SNMP-related candidates 
> will be updated when more accurate information is available.
> 
> 
> 
> ======================================================
> Candidate: CAN-2002-0013
> URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013
> Final-Decision:
> Interim-Decision:
> Modified:
> Proposed:
> Assigned: 20020110
> Category: SF/CF/MP/SA/AN/unknown
> Reference: ISS:20020212 PROTOS Remote SNMP Attack Tool
> Reference: URL:http://www.iss.net/security_center/alerts/advise110.php
> Reference: CERT:CA-2002-03
> Reference: URL:http://www.cert.org/advisories/CA-2002-03.html
> Reference: CERT-VN:VU#854306
> Reference: URL:http://www.kb.cert.org/vuls/id/854306
> 
> Vulnerabilities in the SNMPv1 request handling of a large 
> number of SNMP implementations allow remote attackers to 
> cause a denial of service or gain privileges via (1) 
> GetRequest, (2) GetNextRequest, and
> (3) SetRequest messages, as demonstrated by the PROTOS 
> c06-SNMPv1 test suite.  NOTE: It is highly likely that this 
> candidate will be SPLIT into multiple candidates, one or more 
> for each vendor.  This and other SNMP-related candidates will 
> be updated when more accurate information is available.
>