Common Vulnerabilities and Exposures | CVE

Once vulnerability information has been collected, it must be categorized and evaluated. The methods of evaluation and categorization vary by vendor. This is one key area where many products attempt to distinguish themselves. When a vulnerability is identified, the category is typically assigned according to the type of exploit required or the level of access that is granted. For the purposes of this discussion, we will avoid any vendor-specific approaches and use MITRE’s CVE methodology. According to MITRE’s Web site:

CVE is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this common enumeration.

Structure

MITRE is a non-profit organization that has been making a valuable contributions to VM for years. They have been able to provide an open, standardized platform for the sharing of vulnerability knowledge. When someone discovers a new vulnerability, they frequently (but not always) report this discovery and its details to MITRE, who quickly publishes the information. Unfortunately, standards are still difficult to get adopted in products. 

Every CVE is given an identifier. In effect, this identifier allows a variety of tools from different vendors to speak the same language. A CVE provides the same description for all vendors and the same references to additional information sources. For example, “CVE-2001-0010: Buffer overflow in transaction signature (TSIG) handling code in BIND 8 allows remote attackers to gain root privileges.” This is the same understanding for everyone. It cannot be confused among various vendors.

The references in the CVE will ultimately lead a vulnerability manager to the National Vulnerability Database (NVD) run by the NIST. CVE-2001-0010, mentioned earlier, has related information in the NVD, as shown in Figure 1:

• Overview: This is a summary of the vulnerability that resembles the CVE description.
• Impact: The impact section attributes a score to the vulnerability should it be exploited. More on this later when we discuss the Common Vulnerability Scoring System (CVSS).
• References to advisories, solutions, and tools: These are typically Internet references to obtain more-detailed information about the vulnerability, how to detect it, and how to remediate. In this example, information about patches from various vendors is supplied.
• Vulnerable software and versions: A list of the version numbers that are known to possess this vulnerability. This further helps with the detection process.
• Technical details: This is information about the exact nature of the vulnerability; for example, how the software will react when exploited and why this is bad. Again, this item usually contains links to the site where the researcher has published information about his discovery.

Vulnerability Summary CVE-2001-0010 Original release date: 2/12/2001 Last revised: 5/2/2005 Source: US-CERT/NIST Overview Buffer overflow in transaction signature (TSIG) handling code in BIND 8 allows remote attackers to gain root privileges. Impact CVSS Severity (version 2.0 incomplete approximation): CVSS v2 Base score: 10.0 (High) (AV:N/AC:L/Au:N/C:C/I:C/A:C) (legend) Impact Subscore: 10.0 Exploitability Subscore: 10.0 Access Vector: Network exploitable Access Complexity: Low Authentication: Not required to exploit Impact Type: Provides administrator access, Allows complete confidentiality, integrity, and availability violation , Allows unauthorized disclosure of information , Allows disruption of service References to Advisories, Solutions, and Tools CERT/CC Advisory: CA-2001-02 Name: CA-2001-02 Type: Advisory , Patch Information Hyperlink: http://www.cert.org/advisories/CA-2001-02.html External Source: Security Focus (disclaimer) Name: bid 2302 Type: Advisory , Patch Information Hyperlink: http://www.securityfocus.com/bid/2302 External Source: PGP Security (disclaimer) Name: Vulnerabilities in BIND 4 and 8 Type: Advisory , Patch Information Hyperlink: http://www.pgp.com/research/covert/advisories/047.asp External Source: REDHAT (disclaimer) Name: RHSA-2001:007 Hyperlink: http://www.redhat.com/support/errata/RHSA-2001-007.html External Source: NAI (disclaimer) Name: 20010129 Vulnerabilities in BIND 4 and 8 Hyperlink: http://www.nai.com/research/covert/advisories/047.asp External Source: DEBIAN (disclaimer) Name: DSA-026 Hyperlink: http://www.debian.org/security/2001/dsa-026 Vulnerable software and versions Configuration 1 IS, BIND, 8.2.2 P7 IS, BIND, 8.2.2 P6 IS, BIND, 8.2.2 P5 IS, BIND, 8.2.2 P4 IS, BIND, 8.2.2 P3 IS, BIND, 8.2.2 P2 IS, BIND, 8.2.2 P1 IS, BIND, 8.2.2 IS, BIND, 8.2.1 IS, BIND, 8.2 Technical Details Vulnerability Type No vulnerability type mapping is available. CVE Standard Vulnerability Entry: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0010 Common Platform Enumeration: http://nvd.nist.gov/cpe.cfm?cvename=CVE-2001-0010

Figure 1: CVE-2001-0010.

Notice that CVEs are identifiers and not actual technical details. The main purpose of a CVE is to provide a cross-platform standard for identification of vulnerabilities. To support the quality of this identification mechanism, each vulnerability is subjected to a review process. At first, candidate status is given. This status means that the information is out there but has not been granted CVE status. A CVE editorial board discusses the merits of the candidate and votes on whether or not the vulnerability should receive full CVE entry status.

There are some caveats to the CVE database. First, it is not a vulnerability database. It is a database of vulnerability references. Second, it does not include all known vulnerabilities. It only contains those that are publicly known. So, it is possible that a vulnerability exists of which a vendor or researcher is aware but it does not appear in the CVE list. In some cases, this is because the researcher has agreed with the maker of the software that he will not reveal the vulnerability until a public patch has been released. Naturally, the researcher will want credit for the discovery.

To continue our CVE discussion, CVEs have one of two statuses: candidate or entry. An editorial board must vet the proposed vulnerability prior to it being granted entry status. Until that time, the vulnerability has candidate status. This status is provided on the CVE list when you view the details. When reading a CVE, check this status and review the reference to form your own opinion about the credibility and accuracy of information provided.

Limitations of CVE

CVE has definite limitations and is by no means an answer to all standards issues related to VM. As previously mentioned, CVE does not have a comprehensive list of all vulnerabilities in existence. Some vendors are able to identify vulnerabilities that CVE does not seem to record. Also, it does not necessarily contain all of the metadata needed to make a vulnerability system perform all of the functions that a technology vendor wishes to perform. Naturally, it shouldn’t since it is intended to provide the common-denominator information useful to everyone.

CVE is not always kept up to date. Many vulnerabilities remain in “CAN” or candidate status for years. One wonders if these vulnerabilities will ever be updated when they are known to be accurate. It is possible that some of these are configuration best practices but not necessarily to be considered vulnerabilities. Inversely, CVE does not contain all product best-practice configuration vulnerabilities since they are too numerous to review and include for the many thousands of products in use around the world.

Inference Scanning | Vulnerability Management

One final method of scanning that is seldom used exclusively for vulnerability identification is inference scanning. This method involves the analysis of data that has already been obtained for another purpose to detect the presence of a vulnerability. For example, a configuration management system may have collected detailed configuration data on targets throughout an organization. The inference scanning process would use non-intrusive methods that involve reading the configuration details from the asset database and analyzing them for vulnerabilities. Easy examples of this are discreet configuration items such as SNMP community string or vulnerability application versions.

Since inference scanning is based on factual information provided during the normal course of gathering configuration data, the reliability of an identified vulnerability is very high. Also, because the vulnerability detection process is not performed by actively probing the host on the network, there is no impact to the target. When used strictly by itself, inference scanning is not always reliable or complete since it would not involve verification by other means. It can, however, be used to augment the previously mentioned scanning processes or as an additional feature to a configuration management product. Furthermore, inference techniques can be used architecturally to make vulnerability scanning more efficient. For example, an active vulnerability scanner might collect all of the possible vulnerability information and record it for analysis; then, the inference engine would be used to analyze that data for vulnerabilities in the host. In a later phase, certain vulnerabilities would be flagged for verification by other means before being given the designation of vulnerable. Overall, inference scanning is a valuable tool but is not sufficient to deliver the most complete, reliable results on its own.