In our last CVSSv3 blog series, we discussed our concerns about having to consider exploit reliability and the requirements to bypass advanced exploit mitigation techniques as part of the ‘Attack Complexity (AC)’ base score. This week, we attempt to wrap up the newly introduced challenges by covering the new ‘Scope (S)’ metric.
“Formally, Scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) when granting access to computing resources (e.g. files, CPU, memory, etc).”
According to the CVSSv3 Specification document, the ‘Scope (S)’ metric introduces the ability to measure the impact of a vulnerability not only to the vulnerable component. This is considered a key improvement of CVSSv3. The lack of this capability in CVSSv2 was problematic for vendors and the reasoning for this change is documented in the CVSSv3 User Guide.
When reviewing the ‘Scope (S)’ metric with people, who are new to CVSSv3, it is undoubtedly the change that leads to the most confusion. The reason is that it requires the consideration of authorization and in particular if the vulnerability’s impact crosses authorization boundaries or, said another way, into different permissions. A simple way to think about this would be code running with specific permissions within a Virtual Machine (VM) guest. The vulnerability would allow an attacker within the guest to break out of the VM and be able to take actions on the host. While the CVSS SIG has attempted to simplify this metric from early proposals, it is still not straight-forward to wrap one’s head around the issue and scoring.
Now, let us be clear, we view the ‘Scope (S)’ metric as a special beast. It does add value and provides advantages when scoring some types of vulnerabilities – specifically virtualization as one of its primary focus points. In other cases it is cause for concern. We are planning a future blog post in this series that will discuss our views on advantages of CVSSv3 over CVSSv2; we’ll revisit the ‘Scope (S)’ metric there and cover the positive aspects it provides. In this blog, we’ll just focus on the concerns.
How Well Do You Understand Your Software / Devices?
The ‘Scope (S)’ metric is not reserved for scoring virtualization issues, where a vulnerability exploited within a guest environment may compromise the host. It is used when dealing with the crossing of any authorization scope including sandboxes. Using it in this fashion makes sense, as the impact of a vulnerability outside a sandbox is far worse than within a sandbox. The problem is that this criteria requires analysts to have significant technical insight into how a vulnerability and vulnerable product / component actually works. This also includes understanding how it may be isolated from other components or even the system itself. And keep in mind that this is not just for few products, but for every single scored device, software, and operating system. While vendors that are scoring their own product vulnerabilities should have this knowledge, this is, naturally, unrealistic to expect from others responsible for scoring vulnerabilities.
The concern and limitation is very nicely illustrated by an example provided by the CVSS SIG in the CVSSv3 Specification document when discussing cases where scope changes do not occur:
“A scope change would not occur, for example, with a vulnerability in Microsoft Word that allows an attacker to compromise all system files of the host OS, because the same authority enforces privileges of the user’s instance of Word, and the host’s system files.”
This is actually a pretty bad example, as, in fact, a scope change would very likely occur. Why? Since the release of Microsoft Office 2010 a sandboxing feature called “Protected View” has been included in which untrusted files are opened by default. This limits the access to e.g. files and registry keys to prevent an exploit that “allows an attacker to compromise all system files of the host OS”, unless it somehow manages to cross authorization scopes. Even if a victim disabled “Protected View” and was running Office with administrator privileges, UAC and the integrity mechanism, other authorization scopes in modern Windows versions, would likely limit a compromise of “all system files of the host OS”.
If the CVSS SIG is not aware of this sandboxing feature in a very prevalent piece of software, how can it be expected of analysts or any organization relying on CVSSv3 to score vulnerabilities affecting their infrastructure to be familiar with all these different permissions and security layers?
While that is not a fault with the CVSSv3 standard, it will be a cause of inconsistent scorings when it comes to ‘Scope (S)’ between various security tools, VDBs (vulnerability databases), and other people responsible for scoring. It is important that CVSSv3 consumers realize this limitation, meaning that the ‘Scope’ metrics will most likely only be applied in the most obvious cases and rely heavily on trusting a vendor’s assessment of the vulnerability.
Impact And Scope
Just as we discussed with file-based attack vectors, the new ‘Scope (S)’ metric may also in some cases lead to misleading vector strings. The reason is how the impact metrics should be scored in the case of a scope change.
“If a scope change has not occurred, the Impact metrics should reflect the confidentiality, integrity, and availability (CIA) impact to the vulnerable component. However, if a scope change has occurred, then the Impact metrics should reflect the CIA impact to either the vulnerable component, or the impacted component, whichever suffers the most severe outcome.”
When looking at the vector string for a vulnerability with a scope change, the most reasonable expectation would be for the impact metrics to then reflect the impact outside of the scope. If considering virtualization as an example, that way it would be clear what the impact to the host is. If the impact metrics may convey either the impact inside the original scope or outside, it is impossible to quickly understand the ultimate impact to the host.
Furthermore, when a scope change occurs, the ‘Scope (S)’ metric already raises the score. It seems illogical to score based on the worst-case impact to the vulnerable or impacted component and would likely inflate the scores. Something we’ve started noticing as a problem with CVSSv3 in general and plan to discuss in a future blog post about general scoring concerns.
While we are not trying to exaggerate this as a major issue, it is just another indication that vector strings are, unfortunately, no longer as reliable when used as quick pointers, as they were in CVSSv2.
The 10.0 Score Truncation
What is the maximum score for a vulnerability in CVSSv2? If you said 10, you’d be correct! And the only way for a vulnerability to be scored 10 in CVSSv2 is the following vector string that describes a remotely exploitable vulnerability that has no special requirements, does not require authentication, and leads to a full compromise:
Clearly, this is the same for CVSSv3, right? Not exactly. While the maximum score is still a 10, some issues are due to the ‘Scope’ metric being capped at 10 even if technically the vulnerability should be assigned a higher score! Take a look at the following four scoring examples, where the first is the equivalent of what was scored 10 in CVSSv2:
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:H = 9.9 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H = 10.0 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0 (Critical)
While the impact of the 2nd example score is ‘Low’ for two of the impact metrics, it scores a 9.9. This means that the last two with higher impacts only score 0.1 higher, as they end up being capped at 10. The last two even end up scoring the same regardless of one having one impact metric of ‘Low’ and the other having all three set to ‘High’.
Having re-read the CVSSv3 Specification, User Guide, and Examples documents, we have not seen this mentioned anywhere. The User Guide document even covers significant changes to CVSSv3 over CVSSv2, but omits this part. In our view, this is a pretty significant change, and it seems to have flown completely under the radar. To be completely transparent, we only more or less accidentally noticed this issue when playing around with the CVSSv3 calculator.
In our view, it is highly problematic that the CVSSv3 risk scoring system does not properly accommodate the changes, and we believe it doesn’t properly convey risk and differentiate vulnerabilities when the ‘Scope’ metric comes into play.
Scope And Its Impact On XSS Vulnerabilities
Believe it or not, Cross-site scripting (XSS) vulnerabilities are also impacted by the new ‘Scope (S)’ metric. According to “section 3.4. Cross Site Scripting Vulnerabilities” in the CVSSv3 User Guide, one of the problems with CVSSv2 was that:
“specific guidance was necessary to produce non-zero scores for cross-site scripting (XSS) vulnerabilities, because vulnerabilities were scored relative to the host operating system that contained the vulnerability.”
AV:N/AC:M/Au:N/C:N/I:P/A:N = 4.3
That equals a low-end ‘Medium’ severity issue, which we believe is pretty accurate for how reflected cross-site scripting vulnerabilities are perceived.
In CVSSv3, since the ‘Scope (S)’ metric is now covering XSS issues, it means they no longer require specific guidance. On the downside, such vulnerabilities now significantly increase in score with a standard reflected XSS scoring:
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = 6.1
Why do we have a 1.8 point jump? Another guideline change requires ‘Confidentiality (C)’ to now be rated as ‘Low’ (C:L), which adds 1.1 points to the score. Then the ‘Scope (S)’ change further adds 0.7 on top of that. Suddenly we end up with an above-average score of 6.1 for a simple reflected XSS. While it remains a ‘Medium’ severity issue, for anyone relying on the actual scores for risk prioritization, the score is now much higher than what is publicly perceived to be the risk. This may result in such vulnerabilities being prioritized over other issues that should receive attention first.
Having the ‘Scope (S)’ metric apply to XSS vulnerabilities lead us to another obvious question:
Why should a vulnerability be considered more severe, because it does not impact the host itself, but the client system?
We should all be able to agree that the risk is higher for a vulnerability in a virtualized environment that impacts the host and not just the guest. The same could be said for a vulnerability outside a sandbox instead of inside it. However, a reflected XSS poses no more risk, because the target happens to be the client system and not the server hosting the vulnerable web application.
It seems that to better reflect (see what we did there?) reality, it would be more appropriate to not apply the new ‘Scope (S)’ metric so broadly, but focus on vulnerabilities, where it actually does lead to an increased risk.
While we do have other concerns introduced by CVSSv3, this is the last portion of our CVSSv3 series discussing these new problems. Next up, we plan to cover some problems with CVSSv2 that still remain in CVSSv3.