Use of Common Vulnerability Scoring System (CVSS) by Oracle
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.
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.
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:
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:
References for CVSS Version 3.0
Common Vulnerability Scoring System v3.0 Specification
Common Vulnerability Scoring System v3.0 User Guide
Common Vulnerability Scoring System v3.0 Examples
Common Vulnerability Scoring System v3.0 Calculator
Oracle Critical Patch Updates and Security Alerts page
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:
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:
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.
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)
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