Use of Common Vulnerability Scoring System (CVSS) by Oracle


Overview

Oracle provides severity ratings for bug fixes released in Critical Patch Updates (CPUs) and Security Alerts. The top-level CPU document, the CPU advisory, contains risk matrices listing security vulnerabilities fixed in that CPU. The risk matrices use the Common Vulnerability Scorning System (CVSS) Base Score to provide information about the severity of the vulnerabilities. CVSS describes itself as "a way to capture the principal characteristics of a vulnerability, and produce a numerical score reflecting its severity". This numerical Base Score ranges 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.

Oracle adopted the latest version of CVSS, version 3.0, in April 2016. The next section explains Oracle's interpretation of this standard to help readers accurately understand the CVSS Base Scores. Major differences in the scoring of vulnerabilities due to the change from the prior version of the CVSS standard, version 2.0, is also explained for the benefit of those familiar with the older standard. Oracle used version 2.0 of the CVSS standard between October 2007 and April 2016. Information about CVSS version 2.0 is included in the later section of this document to help with the interpretation of advisories published during that period.

Oracle conforms to the CVSS version 3.0 standard, but certain interpretations and assumptions are sometime required. The purpose of this page is to clarify Oracle's interpretation of the standard. This page is therefore not intended to replace the CVSS standards but to supplement them. The References sections contain links to both versions of the CVSS standards for those not familiar with them.


CVSS Version 3.0


Scope, Vulnerable Component and Impacted Component

Version 2.0 impacts are always scored relative to the underlying operating system. In version 3.0, Attack Vector, Attack Complexity, Privileges Required and User Interaction are scored relative to the vulnerable component; and Confidentiality, Integrity and Availability are scored relative to the impacted component. Generally speaking, the vulnerable component is the product or product component that contains the vulnerability, and which is listed in the Component column of the advisory risk matrix. The impacted component is the component whose data suffers a loss of confidentiality or integrity, or whose service availability is disrupted.

Local Attack Vector

An Attack Vector of Local indicates that the vulnerable component cannot be accessed directly over a network, but requires an attacker to first connect via an intermediary command interpreter, e.g., a Unix shell or DOS prompt. This is then used to launch the attack by invoking the vulnerable component. Such connections use protocols such as SSH and telnet. In version 2.0, only attacks requiring connections to an operating system command interpreter were considered local, but version 3.0 no longer scores all vulnerabilities relative to the underlying operating system (as discussed above). Therefore, attacks requiring connections to non-operating system command interpreters, such as SQL interpreters, are also considered local attacks.

With respect to Oracle products, an Attack Vector of Local is used for vulnerabilities within a component of a database product that require an attacker to connect to a SQL interpreter before launching the attack. It is important to note that it may therefore be possible for a "Local" attack to be conducted via a network over a large distance.

Blended Threats

Every security vulnerability is considered and scored individually. 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. The same logic is applied to vulnerabilities that produce a result that could lead to further damage without requiring another vulnerability.

Hashed and Obfuscated Information

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 brute force a weak password if its hash is revealed.

Libraries and Similar Non-Executable Code

Some Oracle products are collections of libraries and similar code that is not executable as released by Oracle, as it is designed to be called by third party programs. Oracle Outside In Technology, which is a suite of software development kits, is one example. Scoring vulnerabilities in such products is difficult because the score depends on the third party program that uses such libraries, which is not created by Oracle. For example, a program that passes only trusted data from disk to a vulnerable library presents a lower risk than a program that accepts untrusted and unauthenticated data over the network and passes it to the same library. Oracle choose the set of reasonable assumptions that lead to the highest CVSS Base Score, and typically document those assumptions in the advisory.

Partial+ Rating for Impact Metrics

Prior to the introduction of CVSS 3.0, Oracle used a custom rating of Partial+ to provide additional information for the Confidentiality, Integrity and Availability metrics in CVSS version 2.0. Partial+ was used for vulnerabilities that did not compromise the underlying operating system, but did compromise "a wide range of resources". This custom rating is no longer required in version 3.0.

Mapping Partial for Confidentiality, Integrity and Availability

Confidentiality, Integrity and Availability metric values of Partial in version 2.0 usually map to Low in version 3.0. However, version 3.0 also considers if a loss of confidentiality, integrity or availability has "a direct, serious consequence to the impacted component", and if so, High is used. For example, a vulnerability revealing a single plaintext password is scored as Partial under version 2.0, but High under version 3.0. For this reason, some version 2.0 Partial (or Partial+) metric values become High in version 3.0.

Access Complexity

The Access Complexity metric in version 2.0 was a combination of unrelated concepts. Version 3.0 replaces this single metric with: Attack Complexity, Privileges Required and User Interaction. A vulnerability with an Access Complexity of High in version 2.0 purely because it requires the attacker to have privileges or requires a victim to perform some action will have an Attack Complexity of Low in version 3.0, as such preconditions are covered in the other metrics.

Cross-Site Scripting Vulnerabilities

The version 2.0 standard (specifically, scoring tip #2), gave explicit guidance for scoring Cross-Site Scripting (XSS) vulnerabilities. The added flexibility of version 3.0 eliminates the need for a special rule, and most XSS vulnerabilities will be scored in version 3.0 with Scope Changed and impacts of Confidentiality Low, Integrity Low and Availability None. In most cases the impacted component will be the browser of the user affected by the XSS vulnerability, which is impacted because the attack may cause it to run malicious code.

Temporal and Environmental Metrics

Version 3.0 defines the following three groups of metrics, although CPU Advisories only provide values for base metrics:

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

Oracle do not provide temporal values as the first 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, the following values are suggested:

  • Exploit Code Maturity - 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.

References for CVSS Version 3.0

Common Vulnerability Scoring System v3.0 Specification
https://www.first.org/cvss/specification-document

Common Vulnerability Scoring System v3.0 User Guide
https://www.first.org/cvss/user-guide

Common Vulnerability Scoring System v3.0 Examples
https://www.first.org/cvss/examples

Common Vulnerability Scoring System v3.0 Calculator
https://www.first.org/cvss/calculator/3.0

Oracle Critical Patch Updates and Security Alerts page
http://www.oracle.com/technology/deploy/security/alerts-086861.htm


CVSS Version 2.0


Temporal and Environmental Metrics

Refer to the version 3.0 guidance, except that the "Exploit Code Maturity" metric is named "Exploitability" in version 2.0.

Interpretation Of Complete

Version 2.0 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.

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.

Script Injection Vulnerabilities

Consistent with the explanation in the Blended Threats section, most script injection attacks are considered 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 Oracle has adopted, as explained in the "Blended Threats" section.

References for CVSS Version 2.0

Common Vulnerability Scoring System v2.0 standards guide on the Forum for Incident Response and Security Team (FIRST)
https://www.first.org/cvss/v2/guide

Oracle Critical Patch Updates and Security Alerts page
http://www.oracle.com/technology/deploy/security/alerts-086861.htm

National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD)
https://nvd.nist.gov/

CVSS Calculator on NIST NVD web site
https://nvd.nist.gov/cvss.cfm?calculator&version=2 (CVSS version 2.0)


Document Revisions

  • April 2016 - major rework due to transition to using CVSS version 3.0 in CPU Advisories and Security Alerts.
  • March 2016 - updated links to reflect changes on external websites.
  • 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.