Image
A vulnerability exploitable with network access means the vulnerable component is bound to the network stack and the attacker's path is through OSI layer 3 (the network layer). Such a vulnerability is often termed "remotely exploitable" and can be thought of as an attack being exploitable one or more network hops away (e.g. across layer 3 boundaries from routers). An example of a network attack is an attacker causing a denial of service (DoS) by sending a specially crafted TCP packet from across the public Internet (e.g. CVE 2004 0230).The second, equally great documentation, was section 3.3 of the user guide, which stated:
In CVSS v2.0, Scoring Tip 5 stated: "When a vulnerability can be exploited both locally and from the network, the Network value should be chosen. When a vulnerability can be exploited both locally and from adjacent networks, but not from remote networks, the Adjacent Network value should be chosen. When a vulnerability can be exploited from the adjacent network and remote networks, the Network value should be chosen." 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. This guidance has been improved in CVSS v3.0 by clarifying the definitions of the Network and Adjacent values of the Attack Vector metric. Specifically, analysts should only score for Network or Adjacent when a vulnerability is bound to the network stack. Vulnerabilities which require user interaction to download or receive malicious content (which could also be delivered locally, e.g. via USB drives) should be scored as Local. For example, a document parsing vulnerability, which does not rely on the network in order to be exploited, should typically be scored with the Local value, regardless of the method used to distribute such a malicious document (e.g. it could be a link to a web site, or via a USB stick).This meant that a long standing pet peeve (an overabundance of 9.0+ CVSS scores for browser based vulnerabilities) would now be scored correctly. Unfortunately, the examples document that was released did not agree with this. Specifically, example 21 is a browser-based vulnerability that is classified as ‘attack vector: network’. Based on both sets of language above, this is incorrect. I was not the only one to notice this as commenter Stephane pointed out on a previous State of Security blog post and, based on the username, also on a Cisco Security blog post. Unfortunately, rather than correct a bad example, the decision was made to leave the Network attack vector in example 21, leading to a lack of continuity between the documentation and the examples. The CVSS SIG added example 22 to version 1.3 of the examples document with an attempt to explain away this discrepancy.
Vulnerabilities where the vulnerable component is a separate program invoked from a browser, e.g., a word processor, and which require user interaction to download or receive malicious content which could also be delivered locally, should be scored as Local. For example, a document parsing vulnerability which does not require the network in order to be exploited should be scored as Local, regardless of the method used to distribute such a malicious document (e.g., it could be a link to a web site, or via a USB drive).However, for this vulnerability, a PDF file opened in Google Chrome is automatically displayed using the PDFium functionality that is part of the browser. In such cases where the victim could load a malicious PDF file either via a network or from local media (e.g., a hard disk or USB drive), we score Attack Vector as Network, as this gives the higher Base Score. Vulnerabilities in functionality added to a browser, e.g., plugins, extensions and add-ons, are treated as part of the browser when determining Attack Vector. For example, a vulnerability in Adobe Flash is scored with an Attack Vector of Network (assuming the victim loads the exploit over a network). Unfortunately, this doesn’t make sense. The initial paragraph states that a vulnerability that does not require the network should be scored as local. The key word there is ‘require’. Yet, the second paragraph contradicts this, removing network as a requirement and making it optional. This completely negates the definition of the Network attack vector provided in the specification and reverts back to the old CVSSv2 scoring guidance rather than the user guide note for CVSSv3. Now, that’s a lot of language above, so let’s see just how clear CVSSv3 is by looking at a single sentence from two of the larger portions of data above.
Vulnerabilities which require user interaction to download or receive malicious content (which could also be delivered locally, e.g. via USB drives) should be scored as Local. In such cases where the victim could load a malicious PDF file either via a network or from local media (e.g., a hard disk or USB drive), we score Attack Vector as NetworkThese two sentences are a clear contradiction of each other, yet both were published by the CVSS-SIG. The first was published in the user guide text, while the second was published in the Version 1.3 update to the example text. The example text clearly comes from someone that agrees with the CVSSv2 scoring guidance but completely disagrees with the previous stance of CVSSv3. As more and more vendors look to move to CVSSv3, there is an immediate need for clarification in this area. My stance, as it has always been, is that network should be reserved for true network vulnerabilities (as the CVSSv3 specification indicates). A vulnerability in the browser (particularly in the PDF viewer or HTML rendering engine) should be considered a local attack vector. I believe this was the original goal of CVSSv3 and one that many people applauded. However, it seems that the definition has been twisted until it’s unrecognizable and that the standard is now littered with scoring inaccuracies and discrepancies. In addition to the CVSSv3 documentation causing confusion, NVD has already started to provide CVSSv3 scores, which follow the broken CVSSv2 scoring guidance causing additional confusion. This issue needs a clear and final comment from the CVSS-SIG and a solidified direction that makes sense to all users before CVSSv3 is widely adopted and the standard becomes too broken and fragmented to consider using. For the sake of clarity, below you will find impact, solution, and outcome statements below.
IMPACT
Currently, CVSSv3 should be considered unusable. A scoring standard where one of the major conventions is completely contradicted within its own documentation is practically useless. The recent addition of the contradictory advice reverts CVSSv3 back to the flawed state of CVSSv2, losing one of its key improvements. It also ensures clusters of high scoring vulnerabilities will appear rather than an even distribution that is more meaningful in the real world.SOLUTION
The original language of CVSSv3 should be maintained:- A vulnerability that requires user interaction to receive or download malicious content that could also be loaded locally should be considered ‘Attack Vector: Local’.
- A vulnerability should only be ‘Attack Vector: Network’ if the software is bound to the network stack (and based on the above, the inference is that it does not require user interaction to receive the malicious content).
