Understanding the Common Vulnerability Scoring System (CVSS)
By Eric P. Maurice-Oracle on Apr 05, 2011
Hi, this is Eric Maurice again!
A few years back, I wrote a series of blog entries discussing Oracle's application of the Common Vulnerability Scoring System (CVSS). However, shortly after the publication of the January 2011 Critical Patch Update, I saw a number of inaccurate claims made about Oracle's application of the CVSS standard. In this blog, I will attempt to explain how CVSS Base Scores are computed by Oracle, and highlight the limitations of the CVSS standard as it now exists (version 2.0).
In a nutshell, CVSS is an open standard designed to allow organizations to understand the criticality of security vulnerabilities and assess the priority given to security patching. It is platform and technology independent; in practice, CVSS scores can be used to rate security vulnerabilities (to get an indication of their relative severity) affecting a very wide range of software products: operating systems, web and legacy applications, security products (firewalls, antivirus software, etc.), databases, etc.
An overall CVSS Score is actually composed of 3 sub-scores (the "Metric Groups"): the Base Score, the Temporal Score, and the Environmental Score. The CVSS' "Complete Guide to the Common Vulnerability Scoring System Version 2.0" provides the following definitions:
- The Base Score reflects "the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments."
- The Temporal Score reflects "the characteristics of a vulnerability that change over time but not among user environments."
- The Environmental Score reflects "the characteristics of a vulnerability that are relevant and unique to a particular user's environment."
The CVSS Scores provided by Oracle in the Critical Patch Update and Security Alert Advisories are CVSS Base Scores.
Oracle does not provide Temporal Score or Environmental Score for the vulnerabilities fixed in the Critical Patch Updates or Security Alerts. This is mostly because the computation of the Temporal Score by Oracle would have limited value to customers because two of the three factors affecting the Temporal Score would never change (The Remediation Level would always be "Official Fix", and the Report Confidence would always be "Confirmed"). In addition, Oracle cannot compute the Environmental Score because this score is specific to the customers' environment (about which Oracle has no or very little insight).
The Base Scores reported by Oracle in its risk matrices are computed from six criteria, known collectively as the "Base Metrics". These Base Metrics represent "the most fundamental, immutable qualities of a vulnerability". The CVSS documentation states:
"The base metric group captures the characteristics of a vulnerability that are constant with time and across user environments. The Access Vector, Access Complexity, and Authentication metrics capture how the vulnerability is accessed and whether or not extra conditions are required to exploit it. The three impact metrics measure how a vulnerability, if exploited, will directly affect an IT asset, where the impacts are independently defined as the degree of loss of confidentiality, integrity, and availability. For example, a vulnerability could cause a partial loss of integrity and availability, but no loss of confidentiality."
Let's now have a more in-depth look at the 6 Base Metrics.
The first three metrics ("Access Vector", "Access Complexity", and "Authentication") describe where an attack can be launched (Access Vector); related issues such as requirements for social engineering, critical timing or need for high privileges (Access Complexity); and authentication levels required for successful attacks (Authentication). These criteria are designed to provide a good indication of the difficulty of launching a successful attack by people who already have a working exploit.
- The Access Vector metrics measures how the vulnerability is exploited, and specifically how remote an attacker can be to successfully exploit the vulnerability. The possible Access Vector values are "Local", "Adjacent Network", and "Network". The more remote to the targeted host the attacker can be, the higher the score. For example, the "Network" value is used to describe the most severe vulnerabilities, often referred as "Remotely Exploitable" vulnerabilities.
- The Access Complexity metrics measures "the complexity of the attack required to exploit the vulnerability once an attacker has gained access to the target system". The possible Access Complexity values are "High", "Medium", and "Low." Obviously, the lower the Access Complexity, the higher the vulnerability score.
- The Authentication metrics reflects "the number of times an attacker must authenticate to a target in order to exploit a vulnerability." However, "This metric does not gauge the strength or complexity of the authentication process, only that an attacker is required to provide credentials before an exploit may occur." The possible values are "Multiple", "Single", and "None." Obviously, the lower the number of times an attacker has to authenticate, the greater the score of the vulnerability. The most severe vulnerabilities require no authentication (the reported Base Metrics is "None").
In my experience, The Access Complexity metrics is commonly misunderstood. Access complexity does not mean "the degree of difficulty in constructing an exploit". Rather, it means "the degree of difficulty in launching a known exploit". The best way to understand it is through an example. Let's look at 3 hypothetical vulnerabilities:
- The first vulnerability is a RPC (Remote Procedure Call) buffer overflow in a web (Internet) server. Anyone over the Internet can exploit such a vulnerability without requiring any additional steps. As stated in the CVSS standard, there are "no specialized access conditions or extenuating circumstances." The Access Complexity metrics in this example is "Low."
- The second hypothetical vulnerability is a phishing attack, where the victim's web browser is tricked into showing a false link. In such an example, "a small amount of social engineering that might occasionally fool cautious users" exists. The user has to be tricked into clicking the malicious link. The Access Complexity metrics in this example is "Medium."
- The third hypothetical vulnerability is a DNS Hijacking. In such an example, very specific conditions exist to leverage the vulnerability: "the attacking party must already have elevated privileges, or spoof additional systems in addition to the attacking systems." The Access Complexity metrics in this example is "High."
The last 3 Metrics ("Confidentiality Impact", "Integrity Impact", and "Availability Impact") define the possible unauthorized impact of the vulnerability. They are used to assess the confidentiality, integrity, and availability impacts against the targeted system of the successfully exploited vulnerability. The possible values for the three Impact Metrics are the same: they are "None", "Partial", and "Complete."
In my experience, while the scope of the confidentiality, integrity, and availability (CIA) impacts are mostly well understood, the determination of their respective score is perhaps the least understood aspect of the CVSS Base Score. There seems to be some confusion about the use of "Partial" vs. "Complete." The following information is directly extracted from the CVSS Guide:
1. Confidentiality Impact Scoring Evaluation:
• None (N) - There is no impact to the confidentiality of the system.
• Partial (P) - There is considerable informational disclosure. Access to some system files is possible, but the attacker does not have control over what is obtained, or the scope of the loss is constrained.
• Complete (C) - There is total information disclosure, resulting in all system files being revealed. The attacker is able to read all of the system's data (memory, files, etc.)
2. Integrity Impact Scoring Evaluation:
• None (N) - There is no impact to the integrity of the system.
• Partial (P) - Modification of some system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is limited.
• Complete (C) - There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the entire system being compromised. The attacker is able to modify any files on the target system.
3. Availability Impact Scoring Evaluation:
• None (N) - There is no impact to the availability of the system.
• Partial (P) - There is reduced performance or interruptions in resource availability.
• Complete (C) - There is a total shutdown of the affected resource. The attacker can render the resource completely unavailable.
The above definitions imply that when a system's compromise is limited to the software layer in which the vulnerability resides (e.g. a database), the reported value must be "Partial." However, when the successful exploit of the vulnerability results in a full compromise down to the Operating Systems level, the reported value must be "Complete."
Oracle always tries to follow the standard in the application of these scores, and where it is ambiguous, Oracle tries to follow the common usage in the industry. The standard and the industry treat these values as "No Impact" for "none", "Partial Impact" for "Partial" and "Complete compromise of the Operating System where the code is executing" for "Complete". This means that, for example, a complete compromise limited to the Oracle Database Server , but not resulting in completely compromising the Operating System where the Database executes, is considered "Partial".
However, Oracle determined that many customers consider a complete compromise of the Database or other components, just as important as a complete compromise of the Operating System where the Database executes. Consequently, in order to convey the information that the impact is a complete compromise of the affected component, Oracle created the "Partial+" custom score. Oracle uses the Partial numeric value assigned by CVSS for both Partial and Partial+, so that Oracle does not deviate from a strict application of the standard. However, Oracle recognizes that some organizations may choose to deviate from the CVSS standard and discretely inflate the Base Score when a value of Partial + is reported by Oracle in the Critical Patch Update and Security Alert risk matrices. This approach was chosen after Oracle considered using a "Complete minus" score, which would score like an OS complete compromise, but we rejected this approach as it would clearly violate the CVSS standard.
A basic understanding of the CVSS Base Score can bring organizations a long way in understanding the severity of the vulnerabilities fixed in a given CPU or Security Alert. The following rules of thumb can be used to keep CVSS Base Score in proper perspective:
- A CVSS Base Score greater than 7.5 indicates a compromise down to the Operating System of the targeted system where the product executes.
- A value of 10.0 indicates an easy, over the network, unauthenticated, and full takeover down to the Operating System where the product executes.
- A value of 9.0 typically indicates a relatively easy, over the network, and full takeover of the system down to the Operating System, where the product executes, but a low privilege authentication is required.
- A value of 7.5 with no "Complete" value reported in the impact columns of the risk matrix indicates an easy, over the network unauthenticated takeover of the product. (A value of 6.5 would be reported if all impacts were reported as "Partial+" and if authentication was required.)
In January 2011 (with the release of the January 2011 Critical Patch Update), Oracle enhanced the Critical Patch Update documentation by starting to publish a plain English version of the risk matrices contained in the Critical Patch Update advisory. This text summary of the risk matrices will include the same information as the standard risk matrices, and is designed for individuals who are not yet very familiar with the application of the CVSS standard and its interpretation. The link for the plain English version of the risk matrices is provided in each Critical Patch Update advisory (for example, the Advisory for the January 2011 CPU is located here, and the plain English version of the risk matrices is located here). I highly recommend that administrators, who need to consult the CPU advisories, take advantage of the plain English version of the risk matrices to become familiar with the CVSS Standard and its application by Oracle.
For More Information:
- The white paper "Recommendations for leveraging the Critical Patch Update & maintaining a proper security posture" is located at http://www.oracle.com/us/support/assurance/leveraging-cpu-wp-164638.pdf. This white paper has an extensive section on how to properly interpret Oracle's risk matrices.
- Support Note 394487.1 (subscription to My Oracle Support required) explains Oracle's implementation of the CVSS standard.