[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CD PROPOSAL: DOT (Interim Decision 8/24)
>Content Decision: DOT (Use of Dot Notation) >------------------------------------------- > >VOTE: ACCEPT > >(Member may vote ACCEPT, MODIFY, REJECT, or NOOP.) > > > >Short Description >----------------- > >In some cases where a CVE vulnerability may occur at a higher level of >abstraction than might be expected, the Editorial Board may decide to >specify the "instances" of that vulnerability using Dot Notation. Any >database which links to the CVE name must be able to handle searches >that are specified using Dot Notation; but that database is not >required to use Dot Notation itself. Each "instance" is recorded >within the vulnerability's description and annotated with a number. > > >Definitions >----------- > >Dot Notation is an enhancement to the CVE name whose presence >explicitly indicates that a lower level of abstraction is being used. >A number is appended to the CVE name and separated by a dot, e.g.: > > CVE-1999-NNNN.1 > CVE-1999-NNNN.2 > CVE-1999-NNNN.3 > >When a CVE vulnerability has Dot Notation associated with it, the >notation is recorded in the description, e.g.: > >> Buffer overflow in the strcpy() call in function(), as used by the >> following applications: >> >> 1. VendorA ProductA >> >> 2. VendorB ProductB >> >> 3. VendorC ProductC > > > >Rationale >--------- > >In some cases, vulnerabilities may be recorded in the CVE at a higher >level than expected, e.g. due to the HIGHCARD content decision. In >other cases, a content decision may be adopted which is theoretically >consistent but difficult to accurately determine in practice, >e.g. SF-CODEBASE. > >However, for Enumerable vulnerabilities, it may benefit a significant >portion of the users of the CVE to have "access" to a naming >convention at the lower level of abstraction. Dot Notation could be >useful in this fashion, and the Editorial Board may elect to use Dot >Notation to identify specific "instances" of such a vulnerability. > >As a general rule, if a vulnerability can be sub-divided into >approximately 20 "instances" or less, then Dot Notation could be used. > > > >Examples >-------- > >The Same Codebase (SF-CODEBASE) content decision recommends that two >vulnerabilities that are subject to the same attack (e.g. a buffer >overflow using a particular protocol command) should be distinguished >if they come from different codebases, i.e. different authors. >However, in many cases, it is is difficult or impossible to determine >whether two programs have the same codebase. This is especially >problematic with Unix, since there are different "families" and >origins, with numerous modifications. Such vulnerabilities are prime >beneficiaries of dot notation, since the higher level vulnerability >preserves the accuracy of the CVE, while the dot notation facilitates >an attempt to provide more precision. > >A well-defined list of privileges, access rights, or operations that >all appear on the same dialog box could also benefit from a dot >notation, e.g.: > >>Inappropriate use of a Windows NT user privilege: >> >>1. Act as System >>2. Add Workstation >>3. Backup >>4. Change System Time >>...