Jim Knoble <jmknobleat_private> said: >I can't seem to find any information about this issue at cve.mitre.org; >it simply says: > > ** RESERVED ** This candidate has been reserved by an organization or > individual that will use it when announcing a new security problem. > When the candidate has been publicized, the details for this > candidate will be provided. > [Background: CVE is a naming standard for computer vulnerabilities that is being increasingly used by security product vendors and services, as well as software vendors. It is led by MITRE and supported by many leading security-related organizations.] These "** RESERVED **" candidates arise because of a necessary "race condition" in the CVE process. It is best to have CVE candidate names in vulnerability reports when they are first released to the public, especially for issues that affect multiple vendors. This makes the candidate numbers immediately available to people who use them, and it makes it easier to correlate multiple reports or advisories that are describing the same issue. MITRE provides certain organizations with candidate names before the issue has become public. To ensure that there is no "information leak" of vulnerability details before the related issue has been publicized, a generic description is initially assigned to the candidate, as quoted above. The reserved candidate is then placed on the CVE web site to ensure that *something* is there when the issue has been publicized. A short time after the issue has been publicized (normally 0 to 2 business days), the candidate is given a legitimate description and references, and the CVE web site is updated accordingly. So, there's a built-in delay with these "reserved" candidates. Note that there are now details available for CAN-2002-0048. >I've seen at least three announcements about rsync from different Linux >distribution vendors, but no information at all about what versions are >actually vulnerable, or when the vulnerability was discovered (or >fixed). Some people try to use CVE as an original source of vulnerability information, but it is not designed to provide these kinds of details. (Other information sources, such as vulnerability databases and reporting services or vendor and researcher advisories, should be consulted instead). CVE's focus is on providing enough information for people to understand which vulnerability is being identified, to allow them to distinguish between similar vulnerabilities, and to allow prople to correlate information from other sources. That said, it does seem to be difficult sometimes to get the necessary information from an advisory. It's not just version numbers. For CVE's purposes, I have found that the following details are critical: 1) The affected version(s) and product names, and which versions have been fixed. 2) Whether the problem is remotely or locally exploitable (for some definition of "remote" and "local;" there are some variations in how these words are used) 3) The general type of the problem (buffer overflow, signedness error, misconfiguration, etc.) 4) In the case of a researcher or third party advisory: some information about whether the vendor was informed, who was informed, what their response was (if any), and (where possible) a pointer to a place where the vendor publicly acknowledges the problem. 5) Cross-references to other documents (e.g. Bugtraq posts, CERT advisories, and/or CVE names). For vendor or third party advisories, crediting the person who reported the problem will often help to correlate the document with others (though that can still be insufficient information, e.g. when a prolific researcher finds different bugs in the same software over a period of time, and some vendors are reluctant to credit people who don't report a problem responsibly). 6) If similar vulnerabilities have been discovered in the past, a distinct statement that references those earlier vulnerabilities, and says why they are different. Obviously there is more information that other people need, such as links to patches, detailed analysis of the vulnerability, or some notion of how severe the problem is. >I find it tiring that vendors neglect to disclose this sort of >information in their public announcements. A simple statement such as >"Plain-vanilla versions of rsync less than 2.5.2 are vulnerable. >However, we've backported the fix to our sparkling new package of >rsync-2.4.6. Customers who use our Strawberry Linux Forever >distribution should upgrade to our packages, listed below: ...." In the case of version numbers in Linux advisories, sometimes the version numbers are buried in the list of RPM's for fixes (since the filename may contain the version number). The problem is made worse because different Linux distributions will fix different versions of the same software. Another issue occurs when "wildcards" are used to specify ranges of versions that are affected, for example, when someone says "this problem appears in version 4.x." (or worse, "in all versions"). In the future, the vendor may release many other non-vulnerable versions that would appear to "match" the 4.x version. For example, consider when the vendor fixes the problem in version 4.5, and someone sees the advisory after they've installed version 4.10. Old CERT/CC advisories from the early 1990's would sometimes use the wildcard phrases; if those advisories were interpreted literally today, they'd still apply to current software. For example, CERT CA-1991-19 still says "This patch is available for all AIX releases ... to the current release." Listing specific range(s) of affected versions would address this problem. One would think that most consumers of vulnerability information need to know at least (1) the affected version numbers, (2) whether the problem is remote or local, (3) some idea of the severity of the issue, and (4) cross references. But many advisories don't even contain this information. This makes things harder for consumers of vulnerability information, including CVE, because it makes it extremely difficult to distinguish between similar vulnerabilities, or to tell if 2 different reports are really talking about the same issue. CVE can help to address the problem of correlating multiple reports and distinguishing between similar vulnerabilities. However, without direct vendor involvement in CVE, we are often working with the same amount of information that everyone else is... and there are often significant gaps that can produce errors in CVE (and other vulnerability information sources). In fact, we have had to modify some of our own consistency guidelines for CVE content, because many reports do not provide sufficient information. I suspect that erroneous or missing information information often arises when researchers and vendors do not work together to research and resolve an issue. (Yep, it all comes down to disclosure practices.) Sometimes this happens even when people have the best of intentions. Steve Christey CVE Editor
This archive was generated by hypermail 2b30 : Sun Feb 03 2002 - 19:38:14 PST