2/10 CVSS: Not the Meltdown you’d expect

Balázs Kiss
Balázs Kiss
5th January 2018
Balázs has been working in the area of application security for nearly a decade. He is one of the lead trainers at SCADEMY with several years of experience in various fields of software security education.

Please note that the scoring has been updated since the publishing of the original article! This further proves that the debate was valid and the severity needed an update.

Rate my vuln!

The Common Vulnerability Scoring System (CVSS) is the de facto standard for assessing the risk posed by vulnerabilities. It calculates multiple aspects of a vulnerability as numerical 0-10 values: base score (impact, exploitability), temporal score (existence of exploit and fix), and environmental score (modifiers to base score depending on the user’s environment). The final result can also be represented as a single number, which makes it easy to tell a vulnerability’s severity – a low score like 1.2 indicates a very situational hard-to-exploit issue with limited impact, while 10.0 means a critical vulnerability impacting targets worldwide that must be addressed immediately.

There are two versions of the CVSS in widespread use today: CVSSv2 was released in June 2007, while the newer CVSSv3 was introduced in June 2015.

Many vulnerability databases provide their own CVSS assessments for each vulnerability instance – the two most significant ones are the National Vulnerability Database (NVD) and the CERT/CC Vulnerability Notes Database.

As of this writing, NVD doesn’t have CVSS scores for the three vulnerabilities that comprise Meltdown and Spectre (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754). On the other hand, CERT/CC has combined them all into a single entry with its CVSS v2 score an unflattering 2.0 out of 10.0. as of January 5 (update: 5.1 as of Jan 8). That looks surprisingly low, doesn’t it? Does it mean that these vulnerabilities are not really dangerous – or is it a sign of a grave problem within the CVSS scheme itself?

My CPU bleeds for you (and your CVSS score)

Meltdown and Spectre are information leakage-type vulnerabilities stemming from the susceptibility of modern CPU hardware to side-channel attacks. CVSSv2 (or the experts giving the scores) is not at fault here – information leakage vulnerabilities just can’t do too much damage when compared to a remote code execution vulnerability. Usually.

Back in 2014 when Heartbleed started the trend of named vulnerability with scary logo, there was some controversy about it only getting a CVSSv2 score of 5.0 despite being one of the most impactful vulnerabilities ever.

The trend hasn’t changed when looking at information leakage-type vulnerabilities with names that end in -bleed:

This means that even when compared to other ‘bleed’ vulnerabilities, Meltdown/Spectre lose points due to needing local authenticated access to the target system, i.e. executing the attacker’s code on the host. CVSSv2 assumes that a privilege escalation vulnerability is always going to be weaker than one allowing arbitrary code execution. On the other hand, malicious Javascript running inside the browser sandbox (which is one of the main vectors described in the Spectre paper) is not a far-fetched situation at all – users are exposed to a lot of potentially malicious Javascript every day (whether due to visiting dodgy sites, phishing, or cross-site scripting), and browser security strongly relies on Javascript running in a heavily restricted sandbox. It’s not a coincidence that a browser sandbox escape or bypass exploit can be worth around $30.000 on Zerodium, for instance!

Does this mean Meltdown and Spectre – already proven to be massive security problems – are significantly less were assessed to be significantly serious than, say, an Apache memory leakage that also requires misconfiguration? Or that they are on par with a very situational OpenSSL infoleak vulnerability (running arbitrary code on the victim machine while it is doing RSA modulo-exponentiation during decryption on the same core)?

The answer, of course, is a bit more complex than that.

Sometimes, the sequel is better than the original

Put simply: the experts giving the scores are correct, and the even the original 2.0 score is perfectly reasonable – it is just that CVSSv2 does not have sufficient nuance to account for vulnerabilities affecting targets on a global scale with devastating consequences such as the up-to-30% performance drop and potential compromise of entire virtualization-based cloud infrastructures. Similar concerns were raised when Heartbleed was rated only 5.0 back in 2014 despite the massive costs it incurred (estimated on the scale of $500M), and – we assume – this feedback was reflected in CVSSv3 when it was released in 2015.

So what do we get if we translate CERT/CC’s CVSSv2 score of these two vulnerabilities into CVSSv3 as-is, trying to create a 1:1 representation?

  • Attack Complexity goes from Medium to Low since v3 only has Low/High, and High implies preparation or execution against the vulnerable component, which is not the case.
  • Privileges Required is set to Low as the closest match to Single Authentication in v2.
  • User Interaction (new in v3) is set to None.
  • Scope (new in v3) is set to Changed due to privilege escalation from user to kernel mode.
  • Confidentiality Impact is set to Low as a match for Partial in v2.
  • Integrity Impact is set to Low to account for v3’s new approach where follow-up impacts are also considered. In this case, an attacker could obtain some credentials that they can then use to compromise the system’s integrity.
  • For Environmental Score, Confidentiality Requirement is set to High as per v2.

This puts the overall CVSS with no changes to CERT/CC’s metrics at 5.3 – quite some change from the 2.0 it had before.

Using the updated CVSS values from Jan 8 (and following the same process above), we end up with a 6.9 overall CVSSv3 score.

We can, of course, argue about the individual elements. For instance, in our opinion:

  • Privileges Required could be considered ‘None’ since the attack doesn’t require authentication.
  • Confidentiality Impact could be considered High due to the possibility of a full kernel address space dump (or arbitrary read of user-space memory of other processes). The updated CVSS scores reflect this as well.
  • Remediation Level would be a better fit as ‘Workaround’ instead of ‘Official fix’, especially since Spectre claims that proper mitigation is not yet available.
  • Confidentiality Requirement could be considered Medium, since memory-dumping critically important secrets expected to be zeroized after use – such as secret keys – can be very difficult and require precise timing.

This would further increase result in a the CVSS score from 6.7 to even 8.1 . Definitely not what the original 2.0 score tells told us!

It’s always more than a number

By the way, did you know that the same researchers who found Meltdown & Spectre presented a new version of the so-called Rowhammer technique back in October 2017 that leverages Intel Software Guard Extensions to achieve undetectable unauthorized kernel memory modification from the same starting point? A practical implementation of this attack could result in much higher CVSS scores, especially if some other CPU-targeting attacks come to light in the future.

Metrics such as the CVSS score are very useful for prioritizing vulnerabilities and keeping track of the most serious threats to a particular element in your infrastructure – but they should never be considered the sole arbiter of “security-relevancy”. Consider that while these information leakage vulnerabilities are already forcing vendors to cripple their products, it is possible that we’re still just looking at the tip of the iceberg…