Risk Matrix Glossary -- terms and definitions for Critical Patch Update risk matrices

Revised July, 2008.

Purpose

This note explains the information presented in Critical Patch Update advisory risk matrices from October 2006 on.

Scope and Application

The column headings are listed below in the order they appear in the risk matrix. A summary of their purpose is also given.

Risk Matrix Glossary -- terms and definitions for Critical Patch Update risk matrices

Vuln#

A unique vulnerability identifier of a vulnerability.

Starting with the July 2008 Critical Patch Update, Oracle will use industry standard Common Vulnerabilities and Exposure (CVE) identifiers rather than the proprietary identifiers used in previous CPUs. The use of CVE identifiers was adopted to simplify the identification of Oracle vulnerabilities when referenced in external security reports, such as those produced by security researchers and vulnerability management systems.

Prior to the July 2008 Critical Patch Update, the vulnerability identifier was constructed by using a two to four character prefix identifying the product suite containing the affected product and a two character suffix that created a unique identifier within the product suite. Such vulnerability identifiers were unique only within a single Critical Patch Update Advisory.

In either case, vulnerability identifiers can appear in italics.  When vulnerability identifiers appear in italics it indicates that such vulnerabilities have been copied from other risk matrices. This occurs when code from one product suite is included in another. For example, the Oracle HTTP Server is a core part of the Oracle Application Server suite, but ships with the Oracle Database as an optional component. In this example, the Vuln# for an Oracle HTTP Server vulnerability would be italicized when included in the Oracle Database risk matrix.

Component

The product component that contains the vulnerability.

Protocol

The protocol required to attempt to exploit the vulnerability. It may be possible to reduce the risk of attack by limiting access to this protocol. For example, limiting the machines that can form a direct connection to a database using the Oracle Net protocol limits the potential for attack. This is typically achieved using firewalls or managed switches.

Package and/or Privilege Required

Packages, privileges, roles, responsibilities or other preconditions required to attempt to exploit a vulnerability. It may be possible to reduce the risk of attack by changing a required precondition. For example, if a vulnerability may be exploited only by users with access to a certain database package, revoking untrusted users' access to that package will reduce the number of people who can exploit the vulnerability described in this row. Oracle strongly recommends that such changes are first made on a test system as some changes may cause loss of functionality or other unwanted side effects in custom code or other Oracle software.

Remote Exploit Without Authentication?

Indicates if the vulnerability may be remotely exploitable, i.e. attacks may be mounted over a network, by an attacker who does not have authentication credentials for the targeted platform. The CVSS version 2.0 standard (explained below) specifies whether vulnerabilities:

• may be exploited by an attacker on a remote network, an adjacent network or locally;
• require no authentication, a single authentication or multiple authentications.

Vulnerabilities which may be exploitable from a remote or adjacent network, and without authentication, are higher risk and marked with a "Yes". Vulnerabilities which may only be exploited locally or which require authentication are marked with a "No". The information in this column is redundant as the CVSS values on which it is based are available in the CVSS columns, but it allows the list of vulnerabilities to be quickly scanned to locate more serious issues that are newly fixed in this Critical Patch Update.

Version 1.0 of the CVSS standard was used in Critical Patch Update advisories from October 2006 to July 2007. This version of the standard did not include the concepts of an adjacent network nor multiple authentications. For these older risk matrices, this column is marked with a "yes" for vulnerabilities which may be exploitable remotely without authentication.

CVSS Version 2.0 Base Risk

The CVSS version 2.0 base score, an assessment of risk defined by the Common Vulnerability Scoring Standard (CVSS). The document "Oracle's Use of CVSS Scoring" explains Oracle's implementation of the CVSS standard. The full standard, as maintained by the Forum of Incident Response and Security Teams (FIRST), can be found at: http://www.first.org/cvss/cvss-guide.html

The CVSS base score defines the severity of the vulnerability and ranges between 0.0 and 10.0, where 10.0 represents the highest severity. Each risk matrix is ordered using this value, with the most severe vulnerability at the top of each risk matrix.

Version 1.0 of the CVSS standard was used in Critical Patch Update advisories from October 2006 to July 2007. More details of this version of that version of the standard can be found at: http://www.first.org/cvss/v1/guide.html

Earliest Supported Release Affected

The earliest supported release vulnerable to a given issue. Supported releases before the one listed are not affected. Unsupported versions before the one listed have not been tested, but may also be affected by a given vulnerability.

This column was used for all risk matrices in all Critical Patch Update advisories up to October 2007. It was removed in later advisories as its contents can be derived from the information in the Last Affected Patch Set (per Supported Release) column. This can be done by reviewing the Last Affected Patch Set (per Supported Release) column entry to determine which is the earliest Release associated with a patch set that has an entry in this column. For example, DB05 in the January 2008 Critical Patch Update has 9.2.0.8, 10.1.0.5 and 10.2.0.3 in the Last Affected Patch set (per Supported Release) column. These patch sets are from Oracle Database 9iR2, 10gR1 and 10gR2, respectively. Since Oracle Database 9iR2 is the earliest release, 9iR2 is the entry we would have placed in the Earliest Supported Release Affected column if we had retained it.

Last Affected Patch set (per Supported Release)

Product versions that do not have a patch set listed in this entry do not have the vulnerability described in this row in any supported patch set.  Product versions that do have a patch set listed in this entry are subject to the vulnerability described in this row except for patch sets, if they exist, that follow the patch set specified in this entry.  Thus, for example, if an entry in this column for the Database is "10.2.0.4" then Database Version 10g version 2 contains the vulnerability in all supported patch set versions 10.2.0.4 and before while patch sets 10.2.0.5 and later do not have the vulnerability.  Also, in this example, Database versions 9i R2, 10g and 11g would not have the vulnerability in any supported patch set version since no patch set for those versions was specified in this entry.

Notes

Vulnerabilities requiring additional notes will use this column to refer to a Notes section immediately below the risk matrix. This column is included with Critical Patch Update advisories from January 2008 on.