Co-authored by Scott Moore
When the Common Vulnerability Scoring System (CVSS) was updated to its third version earlier this year by FIRST, one of the major questions was what the impact would be on designer vulnerabilities that made earlier headlines and whether the hype matched the new scores.
What’s Actually Different in CVSS v3?
The Access Vector has expanded slightly with the addition of the Physical designation, which requires the attacker to physically touch the affected resource or component. This is a nice addition to the previous indicators that focused solely on electronic infiltration via the network stack or adjacent network access. The Physical vector differs from the local option because, although a malicious file could have been executed by a local user, the attacker does not need to be present.
A base metric called Scope was added to CVSS v3 to address instances in which a vulnerability impacts a component other than the vulnerable component, such as a vulnerability in a Web server that affects the victim’s Web browsers that connect to it, or a vulnerability that breaks out of the sandbox that helps to contain it to a small set of permissions. If a vulnerability Scope is Unchanged, then the vulnerable component and the affected component are the same; that is, only the vulnerable server is affected. If the scope metric is Changed, then the example is like the one above, where a vulnerable server will also affect the browser.
In addition, the Impact vectors were enhanced to account for when sensitive systems or information are affected, such as usernames and passwords being exposed. Impact is broken down into several areas, such as confidentiality, or whether the vulnerability can allow an attack to access confidential data through actions like stealing an admin password (scored High) or some restricted data is obtained or the amount of confidential data is limited (scored Medium).
Another aspect of Impact is Integrity, or the veracity of data, including modifying files protected by the impacted component. The Availability component of Integrity rates the potential downtime for the affected component; a High rating on Availability means that the attacker can fully deny sustained (while the attack is active) or persistent (even after the attack is complete) use of the affected component.
Likewise, a Low rating in Availability means that the component availability will be impacted, but the attacker does not control the impact or the impact is minimally evasive.
Measuring the Impact of Impact (and Scope)
In the Q3 edition of the “IBM X-Force Threat Intelligence Quarterly,” IBM Security X-Force researchers looked at the 2008 DNS Kaminsky bug to see how the schemata stacked up. For this particular example, because the bug affects a vulnerable DNS server, the scope goes beyond just the DNS server and can make a victim of the end user who connects to the server.
Along with the publication of a scoring tool, FIRST provided a document full of sample vulnerabilities to help the industry understand the impact. Out of a total of 21 examples, two-thirds had their score rise, and half of those had their score rise by more than 1 point on the 10-point scale. Some of those with the biggest raise in score include the Kaminsky bug mentioned above, Heartbleed (up to 7.5 from 5), Juniper Proxy ARP DoS (CVE-2013-6014, now up to a 9.8) and a SearchBlox XSS forgery bug (CVE-2015-0970, now up to 8.8).
When Heartbleed hit the scene last year, the outrage over the impact wasn’t reflected in the 5.0 base score, so it’s no surprise that its score, and those of many others, increased. What’s interesting as well are those vulnerabilities whose scores dropped. Most notably, Adobe Acrobat Buffer Overflow (CVE-2009-0658) dropped from 9.3 down to a 7.8 due to the limited scope of the vulnerability. The POODLE bug (CVE-2014-3566) dropped from 4.3 to 3.1, which is just another indicator that marketing budgets should probably be reserved for vulnerabilities with a 7.5 higher score.
If you’d like to do a little research yourself, FIRST has provided a CVSS v3 Calculator on its website. IBM has adopted the v3 schema for any new vulnerabilities posted in the X-Force Database, available for research through IBM X-Force Exchange, our collaborative threat intelligence sharing platform. It’s worth noting that in both the CVE database and IBM X-Force Exchange, vulnerabilities scored before the adoption of the v3 scoring scheme will still reflect the v2 score. Only new vulnerabilities since the adoption of the v3 scheme will show the new score.