Security Curve Weblog

Oracle Vulnerabilities and the CVSS

In the past, I've jumped all over Oracle about their vulnerabilty issues. So when I saw folks alleging that Oracle is potentially downplaying vulnerabilities in their software by under-weighing them (in other words, deliberately misrepresenting the seriousness of the vulnerabilities when coming up with the CVSS score), I was very interested.

Here's the background story: this month, Oracle updated how it represents the seriousness of it's vulnerabilities; instead of using their own proprietary method, they've decided to use the CVSS in their risk profile for these vulnerabilities. They've actually even been so open as to expose the underlying weights that they've plugged in to the CVSS calculations so that customers can see exactly why a certain issue has a particular severity (for example. using the CVSS score calculator here.) Now, the argument is that the numbers are too low; for example, on a 10-point scale, the vast majority are 4 or lower. Sounds pretty damning, right? There are over 100 vulnerabilities including buffer overflows, SQL injection, and a host of other "biggies." But if you drill down on how they're coming up with the numbers, it gets harder and harder to find fault with it (believe me, I've tried.)

For example, the CVSS is a ten-point scale, that's true. But the CVSS is designed such that a vulnerability is weighted according to the impact that it has on the system; a vulnerability that only partially discloses data, for example, is scored less than a vulnerability that fully discloses data. This makes sense, right? What oracle did, in the majority of cases, was use "partial" as the value for "confidentiality impact", "integrity impact" and "availability impact" when some say a "complete" would have been more appropriate. But is that really what they should have done?

Let's take Integrity as an example. Take a look for a minute at the CVSS guide to see what these values are supposed to mean; here's the straight dope on "Integrity" according to the guide (section 1.1.5):

None: No impact on integrity.

Partial: Considerable breach in integrity. Modification of critical system files or information is possible, but the attacker does not have control over what can be modified, or the scope of what the attacker can affect is constrained. For example, key system or program files may be overwritten or modified, but at random or in a limited context or scope.

Complete: A total compromise of system integrity. There is a complete loss of system protection resulting in the entire system being compromised. The attacker has sovereign control to modify any system files.

Now, somebody could make the argument (like Oracle appears to have done) that a buffer overflow in the Oracle software has "partial" impact because it only exposes files accessible to the Oracle account - not the root account. Granted, somebody could escalate privledges after hacking in through the vulnerability, but that's not related to the vulnerability - it's another issue entirely. This interpretation (favorable to Oracle though it might be) seems to be in line with the intent of the CVSS; take a look at the Apache exmaple llaid out in the CVSS guide (section 3.1):

In other conditions, however, the attacker would be able to execute code with the permissions of the web user, thereby altering web content and possibly viewing local user or configuration information (including connection settings and passwords to back-end databases). Therefore, Confidentiality and Integrity Impact metrics are set to "Partial"...

In other words, a literal-minded person, looking at the examples in the CVSS guide, would probably conclude that an application running in a non-root account (e.g. the Oracle database) would have only partial impact to Integrity in the event of a buffer overflow much like was the case with the Apache account in the example. Applying the same logic to all three of confidentiality, integrity, and confidentiality means a difference of three points total for "partial"s rather than "complete"s.

So, if we assume the literal-minded argument, the maximum value for that any Oracle vulnerability could possibly have would be a 10-3=7: or a seven point scale. Is that accurate? Is that the intention of the CVSS? Maybe not. But I don't think Oracle's out of line for interpreting it that way. Sure, the numbers are smaller than you'd expect. And they're probably not reflective of the actual severity of the issue - at least when taken at face value. But is it Oracle's fault? They're applying the criteria as the example; they've been pretty open about "showing their work" so that folks can make their own determinations on risk; and they're using the standard rather than the previous opaque risk value... Maybe they're not in the wrong. Or if they are, somebody should really clarify the intent of the CVSS to make it impossible to mistakenly use the weighting methodology that Oracle did. But that's just my two cents.

Posted by Ed at October 23, 2006 11:24 AM | TrackBack