|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [CD] State of CVE Content Decisions
All, This is a quick note, as I'm heavily occupied with other things such as preparing a new CVE version. 1) Dave Mann and Pascal Meunier have separately brought up the old "dot notation" discussion. We haven't forgotten about this, but in the scheme of things, it's a lower priority than, say, catching up on the backlog of legacy and new candidates. When an abstraction CD causes several issues to be MERGED into a single candidate, the description gives a "bulleted" list of the specific "instances" of that candidate (when those instances are known; sometimes a source says "multiple buffer overflows" but doesn't give more details.) This is the precursor to formalizing dot notation. I'm playing around with a way to link SPLIT issues; I'm not sure whether this should be done via references or a separate "CD" attribute. Here's an example (which should be familiar to those who were interested in last week's SNMP/abstraction thread): ====================================================== Candidate: CAN-2001-0949 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0949 Proposed: 20020131 Assigned: 20020131 Reference: BUGTRAQ:20011204 NMRC Advisory - Multiple Valicert Problems Reference: URL:http://marc.theaimsgroup.com/?l=bugtraq&m=100749428517090&w=2 Reference: CONFIRM:http://www.valicert.com/support/security_advisory_eva.html [Numerous references removed for brevity] Buffer overflows in forms.exe CGI program in ValiCert Enterprise Validation Authority (EVA) Administration Server 3.3 through 4.2.1 allows remote attackers to execute arbitrary code via long arguments to the parameters (1) Mode, (2) Certificate_File, (3) useExpiredCRLs, (4) listenLength, (5) maxThread, (6) maxConnPerSite, (7) maxMsgLen, (8) exitTime, (9) blockTime, (10) nextUpdatePeriod, (11) buildLocal, (12) maxOCSPValidityPeriod, (13) extension, and (14) a particular combination of parameters associated with private key generation that form a string of a certain length. We've been doing this for about 5 months now, but I suppose it would only be apparent to voting members (and this probably answers some lingering questions in some voters' minds ;-) 2) Over time, several Board members have asked where the content decisions are located, and where they can get the most recent copy. The fact is that only some of the CDs are documented well enough for public consumption. In some cases, such as CD:CF-PASS (default passwords), there's a *label* and a 1-line writeup for the CD, but that's about it. For other CDs like SF-LOC and SF-EXEC, we're considering changing the names entirely, to something more mnemonic. 3) The CD documentation has been improved significantly over the past few months, as I've been developing training and reference materials for the content and CNAs. Only the most significant CDs have any reasonable documentation. However, some of them are politically incorrect - they include informal commentary regarding specific issues, and this needs to be cleaned up before publication outside of MITRE's CVE team. 4) My plan is to first post the CDs to the Editorial Board mailing list, along with a notion of how "debatable" they are, then more deliberately integrate them into the CVE web site and the CVE data. This was on my to-do list - *after* the next CVE version. CD:VAGUE keeps cropping up so many times, and it's never been discussed before (unlike most other CDs), so I introduced it "early." 5) MITRE and the charter Editorial Board members learned a hard lesson in summer 1999: we have to be careful about having *too much* discussion and too many topics happening all at once. Right now, CD:VAGUE is getting some attention, and I will be making an announcement later today, which might trigger some additional commentary. So I think it would be better to delay posting the details for other CDs until next week. 6) For those who can't wait any longer, below is a summary of the CDs we're actively using. More detailed explanation will come sometime after I get out the next CVE version and round of new candidates. Note: this is a plaintext version of an HTML document; there are implicit references to links or other web pages that I don't have the time to clean up at the moment. - Steve Content Decisions Index * Abstraction CD's - SF-LOC, SF-EXEC, SF-CODEBASE, CF-DEFAULT, CF-PASS, REDISCOVERY, CF * Inclusion CD's - DEFINITION, VAGUE, EX-BETA, EX-CLIENT-DOS, DESIGN-WEAK-ENCRYPTION, DESIGN-REAL-PATH, EX-ONLINE-SVC Disclaimer Configuration-related CDs are likely to be the most divisive, but they are also the least mature, and they are not consistently applied. Abstraction CD's An Abstraction CD specifies what level of abstraction (level of detail) a issue (or multiple related issues) should be described at, e.g. whether a particular issue should be given 1 candidate or 5 candidates. The basic problem is: different people have different opinions for how to distinguish between issues. Rationales for some abstraction CD's are on this Editorial Board post SF-LOC: Multiple vulnerabilities in the same executable. SF-EXEC: The same apparent vulnerability in multiple executables of the same product or package, or a library that is used by many executables. SF-CODEBASE: The same apparent vulnerability in a codebase that is used by many vendors (major example: most Unix/Linux code) CF-DEFAULT: [**NOTE: THIS IS APPLIED INCONSISTENTLY**] Create a separate entry for a default configuration that is specific to a product and introduces a vulnerability or exposure. CF-PASS: [**NOTE: THIS IS APPLIED INCONSISTENTLY**] This deals with default passwords. The current approach is to create candidates for products that ship with default passwords. This has been hotly debated; some Board members argue that (1) there's a large number of default passwords, which could "explode" the size of CVE, and (2) vulnerability assessment tools may have large collections of passwords in which it can't be determined whether the password was a default, or guessable. REDISCOVERY: (This is an experimental CD). An issue in a particular codebase that is rediscovered in a separate vendor's product at a much later time (1 year or more) may be assigned a different CVE. CF: There are major abstraction issues for managing configuration problems. If a configuration issue is specific to a particular product and there is little variation across different deployments of that product, then it can be included. Inclusion CD's Inclusion CD's specifies whether certain types of vulnerabilities or exposures should go into CVE. DEFINITION: If an issue meets the definition of a vulnerability or exposure, then it may be included in CVE (pending the application of INCLUSION CD's). VAGUE: If a vendor acknowledges or publicizes an issue and says it's security related, but the vendor is vague about the details, it should still be included. EX-BETA: Exclude problems in software that is beta or alpha code unless that version is in wide use. (Example: ICQ is in "permanent beta" and it's in wide use.) Not finalized; create a CAN anyway. Rationale is here. EX-CLIENT-DOS: Exclude client-side DoS that only affects convenience. Not finalized; create a CAN anyway. DESIGN-WEAK-ENCRYPTION: Include problems in which weak encryption is used. DESIGN-REAL-PATH: A configuration or design error that leaks information such as the full pathname for a server is an exposure, so it should be included in CVE. EX-ONLINE-SVC: Exclude problems in online services or ASP's where the problem is specific to that service and does not require additional software by the client. Examples are free mail services (e.g. hotmail), online banking and shopping, etc. NOTE: A problem that's in a separately downloaded client that the vendor can fix at the server is not EX-ONLINE-SVC. Often such problems can still be exploited in direct client-to-client communications. Format CD's DOT: Use "Dot notation" in the CVE description if the entry could be at a higher level of abstraction than "expected" and/or an abstraction CD recommends merging multiple issues that can be separately identified. References 1. http://cve.mitre.org/board/archives/2001-03/msg00012.html 2. http://cve.mitre.org/about/terminology.html#Def 3. http://cve.mitre.org/board/archives/2000-03/msg00009.html
|
||||
