Your search did not match any results.
We suggest you try the following to help find what you’re looking for:
The main page for Oracle’s use of CVSS provides information relevant to all CVSS versions. This page provides Oracle's interpretation of prior versions of the CVSS standard that Oracle used in prior Critical Patch Updates and Security Alerts. Oracle adopted the current version of CVSS, version 3.1, in July 2020, version 3.0 in April 2016, and version 2.0 in October 2007.
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.
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).
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.
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.
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.
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 (i.e., a program not created by Oracle) that uses such libraries. 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.
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
Refer to the version 3.1 guidance, except that the "Exploit Code Maturity" metric is named "Exploitability" in version 2.0.
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.
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.
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.
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
https://nvd.nist.gov/cvss.cfm?calculator&version=2 (CVSS version 2.0)