Use of Common Vulnerability Scoring System (CVSS) by Oracle
Overview
Oracle provides severity ratings for bug fixes released in Critical Patch Updates and Security Alerts. The top-level advisory or alert document contains risk matrices listing security vulnerabilities fixed in the associated patches. The risk matrices use the Common Vulnerability Scoring System (CVSS) Base Metrics to provide information about the severity of the vulnerabilities. CVSS captures the principal characteristics of a vulnerability, and produces a numerical score reflecting its severity. The CVSS formula converts these metrics into a numerical Base Score which ranges between 0.0 and 10.0, where 10.0 reflects the greatest severity. Vulnerabilities in each risk matrix are ordered using this value, with the most severe vulnerability at the top.
Oracle adopted the latest version of CVSS, version 3.1, in July 2020. This page explains Oracle's interpretation of this standard to help readers better understand CVSS information. Previous versions of CVSS, which are used in older advisories and alerts, are explained on a separate page.
Please note that the purpose of this page is to clarify Oracle's interpretation of the CVSS standard. This page is not intended to replace the CVSS documentation, but to supplement it. Links to relevant versions of the CVSS standards are provided in the References sections.
General Scoring Interpretations
Scope, Vulnerable Component and Impacted Component
The Attack Vector, Attack Complexity, Privileges Required and User Interaction metrics 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, 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 exploited directly over a network, but requires an attacker to first connect via an intermediary command interpreter, e.g., a Unix/Linux 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. 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 is therefore 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.
Temporal and Environmental Metrics
CVSS defines the following three groups of 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. The following values are suggested for organizations wishing to generate a temporal score:
- 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.
Environmental Metrics can only be scored by customers as they require knowledge of the environment within which a given vulnerable Oracle product is located.
CVSS Version 3.1
Specific Configurations (Attack Complexity)
The most significant difference between CVSS versions 3.0 and 3.1 is a change in the definition of Attack Complexity. In version 3.0, Attack Complexity considered whether the system being attacked could only be exploited if in a certain configuration. If so, Attack Complexity is High. In version 3.1, if a specific configuration is required for an attack to succeed, the system being attacked is assumed to be in that configuration for the purposes of scoring.
A CVSS version 3.0 score that has an Attack Complexity of High purely because a specific configuration is required for an attack to succeed will have an Attack Complexity of Low when scored with version 3.1. This results in a higher Base Score when scored with version 3.1 than for version 3.0.
References for CVSS Version 3.1
Common Vulnerability Scoring System v3.1 Specification
https://www.first.org/cvss/v3.1/specification-document
Common Vulnerability Scoring System v3.1 User Guide
https://www.first.org/cvss/v3.1/user-guide
Common Vulnerability Scoring System v3.1 Examples
https://www.first.org/cvss/v3.1/examples
Common Vulnerability Scoring System v3.1 Calculator
https://www.first.org/cvss/calculator/3.1
Oracle Critical Patch Updates and Security Alerts page
https://www.oracle.com/security-alerts/