CVSSv2 Access Vector

[Nicholas L 7]

For reasons that are as convoluted as they get, I often have to score things in CVSSv2. Which raises an awful amount questions. One of those questions is always around Access Vector.

The CVSSv2 specification [1] states that the metric value of "Network" is:

Quote

A vulnerability exploitable with network access means the vulnerable software is bound to the network stack and the attacker does not require local network access or local access. Such a vulnerability is often termed "remotely exploitable". An example of a network attack is an RPC buffer overflow.

The question that inevitably arises is if you should score a vulnerability that can be conducted remotely via user interaction as "Network". For example, a user downloads a malicious file and opens it or opens an attachment...etc. Should be an easy "No" right? The problem lies further in the specification documents. Scoring Tip #6 states:

Quote

SCORING TIP #6: Many client applications and utilities have local vulnerabilities that can be exploited remotely either through user-complicit actions or via automated processing. For example, decompression utilities and virus scanners automatically scan incoming email messages. Also, helper applications (office suites, image viewers, media players, etc.) are exploited when malicious files are exchanged via e-mail or downloaded from web sites. Therefore, analysts should score the Access Vector of these vulnerabilities as "Network".

This scoring tip directly contradicts the definition laid out by the specification. Because:

• A malicious file is not bound by the network stack, it can be delivered via USB, created on the vulnerable document, etc...
• Attacker requires local access and is gaining that access through the complicit user

In CVSSv3 the definition was tightened and this type of a vulnerability was clearly indicated to be "Local" but they made the issue worse for CVSSv2 by stating [2]:

Quote

This guidance sometimes led to confusion in cases where an attacker would trick a user into downloading a malformed document from a remote web server, exploiting a file parsing vulnerability. In such case, analysts using CVSS v2.0 would treat these vulnerabilities as "network," producing scores with metric strings of: AV:N/AC:M/Au:N/C:P/I:P/A:P, or AV:N/AC:M/Au:N/C:C/I:C/A:C.

That confusion wouldn't have existed if they didn't contradict their "Network" definition in supplemental "Scoring Tips".

In CVSSv3 and now v3.1, the definition has been expanded but still uses some of the same language. The metric was actually renamed to "Attack Vector" vs "Access Vector" though these are still often mixed up in many vulnerability disclosure reports/articles. So I guess, there are three takeaways I hope one will get from this:

1. Don't be surprised if CVSSv2 has something as Network and v3 has the same vuln as Local. If you are converting between the two, please know the difference.
2. The definition of the metric should be final word, don't change the meaning of the metric in supplemental documentation.
3. If you are a security practitioner, developer of scanning software, or just generally rating/discussing vulnerabilities using CVSS please move to v3 or v3.1 already.  And yes I know, they are both flawed in their own ways.

 

-Nicholas

[1] https://www.first.org/cvss/v2/guide

[2] https://www.first.org/cvss/v3.0/user-guide

[Glenn Pegden 25]

Oooh, as I've found somebody else that cares about CVSS, this is my latest WTF

$Vendor vulnerability for "EOL/Obsolete Software: Apache Tomcat 8.0.x Detected" is listed with a base score of 9.8.

Now, as far as I'm aware, the final release of Tomcat 8 currently has zero reported vulnerabilities. The fact it's EOL is a risk (any newly discovered vulns may not get patches) but it's complete wrong to assign it a CVSS score at all. In my opinion there is no C/I/A impact at all, which obviously gives a score 0 (which is as this is a useful, informational finding, I agree with), but for whatever reason Qualys have gone C:L I:L A:L (full vector is https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L/E:U/RL:U/RC:C  ) which is just nuts!

Don't get me wrong, I'm not advocating EOLed software is ignored, but by doing this I'm sure people are putting resources into do a major version upgrade for something that has no known vulnerabilities, when they could be fixing things that are actually vulnerable. All because (I assume) somebody at $Vendor doesn't know the difference between a risk and a vulnerability.

Edited August 16, 2019 by Glenn Pegden

[Michael D 11]

Interesting food for thought.

Yeah, CVSS has issues, but I'd rather use it and everything that scores via it, than do all of that on my own. There's a lotta busywork involved in the job of vulnerability management, and I prefer to move forward. Besides, CVSS is *usually* a decent indicator, and in those edge cases that it falls over, usually can be handle by analysts case-by-case. Typically as an analyst chases down system owners and they all discuss argue discuss dealing with it.

 

Totally agree, too. EOL software that has 0 open vulnerabilities just has that risk that one will be found eventually. I get that most of the time, EOL software is EOL for a reason (and almost always has security issues latent), but, obviously there are exceptions. 🙂

[Glenn Pegden 25]

I actually a regular defender of CVSS and find much of it's bad reputation comes from people using it the wrong way and/or for the wrong thing. Vendor-generated base-CVSS isn't a great way of ranking vulnerabilities in a specific environment, but that's why we have environmental CVSS (and a distrust of vendor-generated scores).

Edit - Section removed because I am a doofus and exported the wrong field. All vulns do have either CVSS 2 or 3, so I’m calling them ALL out as wrong! 

In previous roles I wouldn't really have cared, "it's stupid to run old stuff, get it patched etc etc etc", but where I am now the difference between a risk and a vulnerability really matters and I'd rather than engineer resource thrown at remediating CVSS 7 actual vulns than software for which there isn't actually a known vulnerability but somebody has slapped an arbitrary 9.8 on it just because it's likely that if vulns are found, no patches are released (which I'll admit is a *risk*). 

Edited August 17, 2019 by Glenn Pegden