Use of Common Vulnerability Scoring System (CVSS) by Oracle



Oracle provides severity ratings for bug fixes released in Critical Patch Updates (CPUs). The top-level CPU document, the CPU advisory, contains risk matrices listing security vulnerabilities fixed in that CPU. This information includes a relative severity of security vulnerabilities calculated using version 2.0 of the Common Vulnerability Scoring System (CVSS). FIRST's web site (see references section), describes CVSS as a rating system "designed to provide open and universally standard severity ratings of software vulnerabilities."

CVSS is interpreted differently by different vendors, but Oracle strives to be consistent with the views of the majority of vendors that use CVSS. The next sections describe how CVSS information provided by Oracle should be interpreted.

Scope and Application

Brief Overview of CVSS

CVSS is a standardized method for assessing security vulnerabilities. For each newly fixed vulnerability in a CPU, Oracle provides values for CVSS metrics indicating:

  • preconditions required to exploit the vulnerability and the ease of exploit; and
  • the impact of a successful attack in terms of confidentiality, integrity and availability.

CVSS uses a formula to turn this information into a base score between 0.0 and 10.0, where 10.0 represents the most severe vulnerability. The risk matrices are ordered using this value, with the most severe vulnerability at the top. This can be used to quickly identify the most serious problems if you do not wish to understand the full CVSS standard.

Use of Common Vulnerability Scoring System (CVSS) by Oracle

Base, Temporal and Environmental Metrics

The CVSS standard includes three groups of metrics:

  • base metrics representing "intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments";
  • temporal metrics representing "characteristics of a vulnerability that change over time but not among user environments"; and
  • environmental metrics representing "characteristics of a vulnerability that are relevant and unique to a particular user's environment".

We do not provide temporal values as one temporal metric depends on the availability of proof of concept or exploit code, which may change over time. If you wish to generate a temporal score, we suggest using the following values:

  • Exploitability - Use Functional by default. Use High if exploit code is widely available and works in every situation or if the vulnerability is being exploited by mobile autonomous code such as a worm.
  • Remediation Level - Official Fix.
  • Report Confidence - Confirmed.

This will yield temporal score modifiers of 0.83 for functional exploitability and 0.87 for high exploitability.

Environmental metrics need to be calculated by customers as they are based on the loss to an organization from a successful attack and the percentage of total machines which are vulnerable.

More details on all the metrics can be found in the CVSS standards guide on the FIRST web site (see references).

Interpretation Of 'Complete'

CVSS rates Confidentiality, Integrity and Availability impacts as None, Partial or Complete. The definition of Complete is defined in terms of the impact to the "system". Most Oracle products run on an operating system, so the system can be considered to be:

  • Just the Oracle software running on a machine; or
  • All software running on the machine.

The former interpretation makes sense in environments where the only important information is maintained by Oracle software. For example, a machine installed with Oracle software and a minimal operating system whose only purpose is to run that software. A vulnerability that leads to operating system superuser privileges provides little benefit over a vulnerability that leads to superuser privileges for just the Oracle software.

The latter interpretation makes sense for scenarios in which Oracle software is not the only application on a machine. In this scenario, a vulnerability that leads to operating system superuser privileges compromises all applications. A vulnerability that leads to superuser privileges for just the Oracle software is less severe.

A sampling of CVSS ratings for vulnerabilities on NIST's NVD web site reveals that different interpretations of Complete are being used, but that the latter is more common. Oracle has adopted the latter interpretation to be consistent with the general use of CVSS.

Addition Of Partial+ Rating

Oracle provides additional information on Partial ratings as follows:

  • Partial - the exploit affects a limited range of resources, e.g. a specific database table.
  • Partial+ - the exploit affects a wide range of resources, e.g. all database tables, or compromises an entire application or subsystem.

The addition of the Partial+ rating does not change the CVSS base metric scoring system. However, customers have all the required information to recalculate the CVSS score with Partial+ ratings changed to Complete, if that is more appropriate for their environment. Customers who do not wish to deal with this level of complexity can simply treat Partial+ as Partial. The NIST NVD web site has an interactive CVSS calculator that illustrates how changes in metric values influence the CVSS scores, and this can be used to recalculate CVSS base scores with modified metric values. See the references section at the end for the link.

Blended Threats

We consider each security vulnerability in isolation. Although it is sometimes possible to combine, or blend, threats to create an attack that is more severe than the sum of its parts, it is clearer to consider each vulnerability individually. CVSS version 2.0 recommends this approach in the standard.

We apply the same logic to vulnerabilities that produce a result that could lead to further damage without requiring another vulnerability. An example is an Oracle HTTP interface leaking a superuser operating system password. We treat this as a Confidentiality issue, and do not further consider what damage may be done with that password as it depends on other factors, e.g. whether the operating system allows the superuser to login directly.

Script Injection Vulnerabilities

Consistent with the explanation in the "Blended Threats" section, we consider most script injection attacks to only affect integrity. This is because most take the form of an attack that modifies data created by the server, usually a web page. This approach does not consider follow-on attacks that may be possible by injecting scripting code that runs on a victim's web browser, but it is consistent with the methodology we have adopted, as explained in the "Blended Threats" section.

Encrypted, Hashed and Obfuscated Information

Encrypted, hashed and obfuscated information is generally treated as if it is plain text. This is a safer approach than assuming that an attacker can gain no benefit from the information. For example, it may be possible to guess a weak password if its hash is revealed.

Local Attacks

Attacks that have an Access Vector of Local assume that the attack starts with the attacker already logged into a shell on the target machine. If no additional authentication is required to exploit the vulnerability, the Authentication metric will be None. This is consistent with the approach taken in the third example in the CVSS 2.0 standard.


Common Vulnerability Scoring System standards guide on the Forum for Incident Response and Security Team (FIRST) (latest version of standard)

Oracle Critical Patch Updates and Security Alerts page

National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD)

CVSS Calculator on NIST NVD web site (CVSS version 2.0) (CVSS version 1.0)

Document Revisions

  • June 2010 - added information about local attacks and removed outdated information regarding older risk scoring systems.
  • July 2008 - minor formatting modifications.
  • October 2007 - update due to transition to CVSS version 2.0.
  • October 2006 - first release of this document to coincide with the first use of CVSS.