Oracle Security Advisories and CVE Identifiers

In a major change to the Oracle security advisory process and Critical Patch Update documentation, CVE identifiers are now used in place of the Oracle proprietary numbering scheme (i.e., DB01, AS01, APP01, etc.).  Common Vulnerabilities and Exposures (CVE) is a standardized dictionary and identifiers of published security advisories.  The purpose of CVE is to provide a single identifier for security vulnerabilities so that vendors, tools, and organizations can all refer to the same vulnerability with a single identifier.  The format of the CVE identifier is (1) a fixed "CVE" to indicate it is a CVE identifier, (2) the year (i.e., 2008), and (3) a sequential number of when the entry was added to CVE (i.e., 2607).  As an example, the first database vulnerability is CVE-2008-2607.

The previous Oracle proprietary numbering scheme had several issues in relationship to CVE numbering -

  1. Oracle provided a mapping to previously released vulnerabilities only for those vulnerabilities in core components like Apache and OpenSSL.  No mapping was provided for previously publicly disclosed vulnerabilities, so there are cases when the same vulnerability has two CVE identifiers.
  2. A single CVE identifier was usually assigned to multiple vulnerabilities in an almost arbitrary fashion.  This meant that a CVE identifier might include vulnerabilities from multiple components and in the case of the Oracle E-Business Suite across multiple patches.  For Integrigy, this caused problems with our vulnerability scanning tool, AppSentry, since our reports have to handle many-to-many mappings when dealing with CVEs, patches, and vulnerabilities.
  3. The CVE numbers were usually assigned 1-2 days after the Oracle release.

The CVE identifiers in the Oracle advisory does use a single CVE identifier per vulnerability and maps directly to previously disclosed vulnerabilities (see CVE-2007-1359).  Although it would have been nice if Oracle had included hyperlinks in the advisory to either CVE or NVD for easier access.  It will be interesting to see if CVE-2007-1359 is fixed in this CPU as either CVE-2008-2589, CVE-2008-2594, or CVE-2008-2609, which would reduce the effectiveness of using the CVE identifiers and again result in duplication of vulnerabilities in CVE if CVE identifiers for previously disclosed vulnerabilities are not used.

Using the CVE Identifiers

Additional information on vulnerabilities can be found either in the CVE or the National Vulnerability Database (NVD) sponsored by the Department of Homeland Security.  NVD contains the most detailed information including a break-down of the CVSS2 score and links to external references that may have more information on the vulnerability.  The typical process is that a generic NVD is created with only a reference to the original Oracle advisory.  When there is public disclosure with additional details on the vulnerability, the NVD entry is updated with links to those disclosures.  This process should be much more timely and accurate as most public disclosures will now include the CVE identifier.  Usually, about 30% of the vulnerabilities per quarter will have additional information and the database vulnerabilities typically have more information than the other products.

An example of a fully populated entry is the ModSecurity vulnerability that was previously fixed in ModSecurity 2.1.1 -

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1359

An example of an entry with additional details is the buffer overflow in the Oracle AQ package SYS.DBMS_AQELM -

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-2607

 Share this post