Oracle and CVSS

Oracle has adopted the Common Vulnerability Scoring System (CVSS) as its standard for communicating the severity of security vulnerabilities in its products.  The critics have already jumped on Oracle for "manipulating" the CVSS scores for the October 2006 Critical Patch Update (CPU) (story here).

First and foremost, I applaud Oracle's decision to adopt CVSS and jettison the old proprietary system.  As more large organizations begin using CVSS, the metrics will become more widely understood and discernible.

The use of CVSS for rating the severity of security vulnerabilities in Oracle products is far from perfect and the resulting scores must be understood to correctly comprehend the risk associated with the patched vulnerabilities.  There are three aspects that need to be considered regarding Oracle's usage of CVSS - (1) the CVSS standard itself, (2) Oracle's implementation of CVSS, and (3) customers interpretation of the vulnerability scores.

The CVSS Standard and Oracle Products

CVSS was clearly developed by network and system security folk (which is probably appropriate considering its purpose) as demonstrated by the heavy weighting on the network device and operating system rather than a metric where network device, operating system, database, and application share a similar weighting.  The CVSS Confidentiality, Integrity, and Availability values are None, Partial, and Complete.  For a Complete score in any category, the entire "system" must be completely compromised, not just the entire database or entire application.  Thus, the ability for an attacker to "own" the entire database and not the Unix root account will only give you a Partial.  Similar is the case of an attacker able to compromise the Oracle Application Server and fully manipulate the Oracle HTTP Server (Apache) to replace or change any files -- only a Partial.

So fundamentally, an application or database vulnerability can really only score up to a 7, whereas a vulnerability in a network router or server operating can score a perfect 10.  You still lost all your data, but it was only a 7.

The scores become even more whacked out when you only look at one category (Confidentiality, Integrity, or Availability).  If you can easily compromise just the Confidentiality or Integrity of the entire database, remotely, and without authentication, then the score is a 2.3.  Both the Confidentially and Integrity of the entire database would only get you a 4.7. 

My first thought was that if you can compromise both the Confidentiality and Integrity of the entire database, you would most likely be able to affect the Availability and get a score of 7.  Not true.  Of the 11 vulnerabilities in the October 2006 CPU marked Partial+ for both Confidentiality and Integrity, 8 are marked as None for Availability for a maximum score of 4.7 (since authentication is required really only a 2.8).

Of all the database vulnerabilities fixed by Oracle, very few allow you to directly compromise data in the database without authentication.  Usually you have to leverage multiple vulnerabilities or perform other actions once the operating system is compromised (neither Oracle or CVSS take the "blended threat" into account).  This being the case, the maximum scores are even lower for almost all database vulnerabilities.  The realistic maximum score for a database vulnerability is really only 4.2.

Oracle and CVSS Metrics

As shown above, the issue is not with Oracle, but with the way the CVSS metrics work with databases and applications.  Based on a pure interpretation of the CVSS standard, all the Oracle score look appropriate.  I really can't fault Oracle for using CVSS or accuse them of adopting it as a marketing tool because of the low scores calculated for the database and applications, since it is really the only standard of its kind and is supported by the Department of Homeland Security.

To account somewhat for this issue (I have to give Oracle some credit on this one), Oracle has slightly modified the CVSS values (see Metalink Note ID 394487.1) to include Partial+, which means a full compromise of the component (i.e., the database).  However, Partial+ does not change the metric in any way.  Oracle does suggest you change the Partial+ to Complete and recalculate the vulnerability score yourself.  A standard is a standard and should be implemented the same way by everyone (or you end up with something that looks like UNIX).

Oracle has always ignored "blended threats" and only looks at "each security vulnerability in isolation."  With all the buffer overflows and SQL injection bugs in standard Oracle Database functions, SQL injection is an excellent attack vector and it is much easier to exploit these known vulnerabilities than attempting traditional SQL injection methods.  However, "blended threats" are not included in the CVSS score in any way nor is the possibility researched by Oracle.

Customer Usage of CVSS Metrics

Customers really to need to fully understand what the CVSS scores mean and that the scores are not directly comparable to network devices or operating systems scores.  When viewing the scores, I would recommend you use the following guidelines for maximum scores.  These maximums represent a possible complete compromise of the database, server, or application -

Oracle Database = 4.2
Oracle Application Server = 4.7
Oracle E-Business Suite = 4.7

These are the realistic maximum scores attainable for almost all Oracle vulnerabilities in these products.  Yes, it is possible to have higher scores, but it will be a rare event.  The risk matrices need to be reviewed for all vulnerabilities marked with "Partial+", which represent a complete compromise of the product (see Metalink Note ID 394487.1).

Another major issue for Oracle E-Business Suite customers, there is no direct or official mapping of vulnerabilities to patches.  Therefore, the CVSS scores can not be readily used to prioritize patches.  I hope in future Critical Patch Updates, Oracle will provide this mapping.

 Share this post