Every 3 months Oracle release a Critical Patch Update (CPU) which usually applies to a majority of Oracle products. I haven't seen an instance where there was a Critical Patch Update that didn't apply to the Oracle Database. It is good practice to regularly review these advisories when they are released. The simplest form of assessing the Risk Matrix is to see what version and component of a product is affected, whether that product exists in their environment and then apply the CPU.
To give you an idea of vulnerabilities and their seriousness there was recently the release of a zero-day attack for the Oracle database known as the TCP Listener Poison attack. To view the most recent advisories see the below link and select "View the most recent Critical Patch Update Advisory":
The April 2012 advisory (latest at time of this writing):
For each product there is a Risk Matrix. This matrix is the basis for assessing risk to a component associated with a product. I'm only concentrating on the Database product however the same principles in assessing the CVSS (Common Vulnerability Scoring System) applies for other products also.
I have provided a short summary on some of the key aspects in understanding risk matrix and meaning of the CVSS headings. Hopefully for high risks that gives people imperitive to patch and help present a case to management to undertake a patching exercise.
Prior to the Risk Matrix Oracle provide a good summary of the vulnerabilities for a product. From the April 2012 Database advisory:
"This Critical Patch Update contains 6 new security fixes for the Oracle Database Server. 3 of these vulnerabilities may be remotely exploitable without authentication, i.e., may be exploited over a network without the need for a username and password. 1 of these fixes is applicable to client-only installations, i.e., installations that do not have the Oracle Database Server installed.
Below is an excerpt of the April 2012 Database Product Risk Matrix:
Oracle Database Server Risk Matrix
|CVE#||Component||Protocol||Package and/or Privilege Required||Remote Exploit without Auth.?||CVSS VERSION 2.0 RISK (see Risk Matrix Definitions)||Supported Versions Affected||Notes|
|Base Score||Access Vector||Access Complexity||Authen-|
|CVE-2012-0552||Oracle Spatial||Oracle NET||Create session, create index, alter index, create table||No||9.0||Network||Low||Single||Complete||Complete||Complete||10.2.0.3, 10.2.0.4, 10.2.0.5, 220.127.116.11, 18.104.22.168, 22.214.171.124||See Note 1|
|CVE-2012-0519||Core RDBMS||Oracle NET||Create library, create procedure||No||7.1||Network||High||Single||Complete||Complete||Complete||126.96.36.199||See Note 2|
|CVE-2012-0510||Core RDBMS||Oracle Net||None||Yes||6.4||Network||Low||None||None||Partial||Partial||10.2.0.3, 10.2.0.4, 10.2.0.5, 188.8.131.52|
Here is a quick guide to assessing the risk matrix before understanding the CVSS completely for your environment:
Understanding Risk Matrix columns
The columns Base Score, Access Vector, Access complexity, Authentication, Confidentiality, Integrity and Availability are taken from the CVSS verion 2.0 open framework. Oracle have added the "Remote Exploit Without Authentication", and also modified the “Partial” definition to include “Partial+”.
Oracle have also included a few of their own columns in addition to CVSS. These are Component, Protocol, Package and/or Privilege and Remote Exploit without Authentication. These are described here: Risk Matrix Glossary -- terms and definitions for Critical Patch Update risk matrices
This document describes Oracle's use of the CVSS system: Use of Common Vulnerability Scoring System (CVSS) by Oracle
Base Score“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.”
Access VectorThe poorest score is "Network".
Access ComplexityThe poorest score is "Low".
The attack depends on social engineering methods that would be easily detected by knowledgeable people. For example, the victim must perform several suspicious or atypical actions.
The vulnerable configuration is seen very rarely in practice.
If a race condition exists, the window is very narrow.
The attacking party is limited to a group of systems or users at some level of authorization, possibly untrusted.
Some information must be gathered before a successful attack can be launched.
The affected configuration is non-default, and is not commonly configured (e.g., a vulnerability present when a server performs user account authentication via a specific scheme, but not present for another authentication scheme).
The attack requires a small amount of social engineering that might occasionally fool cautious users (e.g., phishing attacks that modify a web browser’s status bar to show a false link, having to be on someone’s “buddy” list before sending an IM exploit).
The affected product typically requires access to a wide range of systems and users, possibly anonymous and untrusted (e.g., Internet-facing web or mail server).
The affected configuration is default or ubiquitous.
The attack can be performed manually and requires little skill or additional information gathering.
The “race condition” is a lazy one (i.e., it is technically a race but easily winnable).
AuthenticationThe poorest score is "None".
ConfidentialityThe poorest score is "Complete".
IntegrityThe poorest score is "Complete".
AvailabilityThe poorest score is "Complete".
Additional Notes about CVSS terms
Here is also a link to the Common Vulnerability Scoring System Version 2 Calculator. I've included it so you can see how a score is calculated. This does not include the Oracle created columns (for eg, there is no Partial+) but still worth having a look at.