CVSSv3: New System, New Problems (File-based Attacks)

This is the second blog post in our series discussing CVSSv3. As shared in the first post, we have been in the process of thoroughly evaluating CVSSv3 to better understand the improvements and limitations compared to CVSSv2 for quite some time. For those curious about our thoughts on CVSSv2, we recommend our “The CVSSv2 Shortcomings, Faults, and Failures Formulation” whitepaper.

Our ultimate goal of this exercise is to conclude if CVSSv3 adds sufficient value over CVSSv2 to justify a switch in our VulnDB vulnerability intelligence solution. As part of this process, instead of keeping all of our analysis internally, we have decided to blog about it, so we could share our observations and thoughts, assisting other organizations also trying to make sense of the changes to the standard.

Often when a new system is created, it introduces new challenges. This blog post focuses on what we believe to be one of the bigger concerns introduced by CVSSv3. Due to the length, a follow-up blog post is going to discuss some additional introduced issues that users may not fully be aware of.

Access Vector: The “Local vs. OSI Layer 3” Convolutedness

One of the changes to the CVSSv3 specification is that vulnerabilities relying on file-based attack vectors e.g. against your favorite PDF reader should no longer be scored as network-based attacks (AV:N), but local attacks (AV:L) even if the attacker is not a local user. These types of attack vectors are usually referred to as “context-dependent” or “user-assisted”, meaning that the vulnerability would not be triggered without some form of user interaction.

An example of this change can be found in example 16, “Adobe Acrobat Buffer Overflow Vulnerability (CVE-2009-0658)”, of the CVSSv3 Examples document.

The reasoning provided by the CVSS-SIG is that the attacker’s path is not through OSI layer 3 (the network layer). Instead, it requires tricking a user into opening a file that ultimately resides on the victim’s system. The fact that the attack vector may be a link to a file hosted on a website that is potentially automatically opened is disregarded. That is, unless the functionality to view said file is implemented within the browser e.g. how Google Chrome and Microsoft Edge support opening of PDF files. In such cases, it should still be treated as a remote issue per example 22.

Wait, what?

Let’s try to sum up: If a PDF file (or any other file type) is passed from the browser to a separate program e.g. opening in Adobe Reader, it becomes a local issue. If the same file type opens within a browser component, it’s still a remote issue – even if the attack vector and amount of user interaction required is exactly the same.

What a convoluted, academic mess!

What does this entail scoring-wise?

Using CVSSv2, this type of vulnerability scores 9.3, which translates into a ‘Critical’ issue (though this term was not used for CVSSv2; NVD just defined “Low”, “Medium”, and “High”). Using CVSSv3, the same issue now scores 7.8 i.e. a ‘High’ severity issue. The score dropping 1.5 points is due to the required user interaction now inappropriately both impacting the ‘Attack Vector (AV)’ metric as well as the new ‘User Interaction (UI)’ metric. We find it suboptimal that user interaction in these cases is not only reflected by the newly created metric for this, ‘User Interaction (UI)’, but also the attack vector, as both contribute to reducing the risk rating.

On the surface, a 1.5 point drop in the score and a severity rating lowered from ‘Critical’ to ‘High’ is perhaps not a major concern for most. That said, file-based attacks leading to code execution are generally considered quite severe and should be prioritized accordingly. Historically, they have been popular in attacks for a reason. Even if a file may end up being downloaded to the system, the attacker is rarely a local attacker, but makes use of a “remote” attack vector. The fact that many organizations will only prioritize “Critical” vulnerabilities to be patched out of cycle or outside a maintenance window makes this an important issue to understand given the potential severity.

Also, consider that a standard local privilege escalation vulnerability is now more severe (scoring 8.4) than code execution via e.g. a malicious PDF, Office, or media file. Scoring aside for a moment, when reviewing the potential risks, which vulnerability would you generally prioritize first? While local privilege escalation vulnerabilities should not be underestimated, the risk of compromise via malicious PDF files opened by unsuspecting users has proven to be a much greater threat in most environments.

To boil this down, it simply means that we believe this is our first example of CVSSv3 scoring now having organization’s prioritize the wrong vulnerabilities to be fixed.

Misleading Vector Strings

A final concern about this change is how it leads to possible confusion conveyed by the CVSSv3 vector string. In CVSSv2, the vector string may be used as a quick way to get an overall impression of a vulnerability’s impact and attack vector without reading the associated vulnerability details (if available; we’re looking at you Oracle).

Currently the vector string for such vulnerabilities is:
CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 7.8 (High)

Based on this, it becomes harder for people to determine if an issue is a local privilege escalation vulnerability requiring some user interaction or really a user-assisted vulnerability relying on a file-based attack vector.

We believe that a much simpler approach would be to score such vulnerabilities as:
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H = 8.8 (High)

While it remains a “High” severity issue, this proposed change we are suggesting does make scoring more straight-forward. Analysts just have to focus on the actual attack vector i.e. an attacker not being a local user and not OSI layer 3 theory. They also do not have to score the same issue differently depending on file types opening directly in a browser component versus another program. User interaction is no longer misleadingly reflected both by the “User Interaction (UI)” metric and “Attack Vector (AV)” metric. Finally, the vector string also remains informative as in CVSSv2 while avoiding confusion.

Fortunately, changing this is quite simply a guideline change and would not require changing the scoring system or the standard itself. While this seems like great news, it is critical to understand that the scoring of CVSSv3 relies heavily on the guidelines, meaning that currently all organizations that are trying to following them, based on this concern really are not helping your organization properly prioritize vulnerabilities.

In the next blog, we’ll discuss a few additional concerns introduced by CVSSv3.

CVSSv3: New System, Next Problem (Exploit Reliability)