Jump to content
  • Recently Browsing   0 members

    No registered users viewing this page.

Nicholas L

CVSSv2 Access Vector

Recommended Posts

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:


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:


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]:


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.



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

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

  • Like 2

Share this post

Link to post

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 by Glenn Pegden
  • Like 1

Share this post

Link to post

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. 🙂

Share this post

Link to post

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 by Glenn Pegden
  • Like 2

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Members online now

    No members to show

  • Create New...

Important Information

We use cookies as we're cookie monsters. Privacy Policy