Tempering the Vulnerability Hype Cycle with CVSS
Hi everyone, it's Todd Lewellen. Today, I want to discuss how quantitative vulnerability metrics, like the Common Vulnerability Scoring System (CVSS), can help to develop a more accurate understanding of a vulnerability's severity.
We notice sometimes that in the heat of public disclosure of a vulnerability, the severity context is sometimes lost or overlooked. Take, for instance, the BREACH vulnerability that was coordinated by the CERT/CC and presented at the Black Hat conference in Las Vegas last week. BREACH is a close cousin to the CRIME and BEAST vulnerabilities in its target, attack vector, and methods.
Some coverage of the BREACH vulnerability has focused on the 'Solution' section of our vulnerability note where we state that "We are currently unaware of a practical solution to this problem." This sentence is default verbiage in our vulnerability notes and is not meant to be an objective quantification of the seriousness of a vulnerability. Those words should be interpreted literally to mean that CERT/CC is not currently aware of a practical solution.
The lack of a straightforward solution for BREACH (such as a patch or update) does not, by itself, make the vulnerability significantly more severe. Any solution or mitigation for BREACH needs to consider interactions between compression and cryptographic protocols and the large existing user base (more or less every modern web server and browser).
So how can CVSS help scope the severity of BREACH? For those of you not familiar with it, "CVSS provides a universal open and standardized method for rating IT vulnerabilities." CVSS is maintained by the Forum of Incident Response and Security Teams (FIRST). While FIRST has provided excellent documentation, I'll provide a very brief synopsis of CVSS scoring here.
CVSS scores are given on a scale of 0.0 to 10.0. The National Vulnerability Database (NVD) classifies any rating below 4.0 as a 'minor' vulnerability; whereas a score of 7.0 or above indicates a 'critical' vulnerability. There are three "metric groups" in CVSS that aim to measure different characteristics of a given vulnerability: Base, Temporal, and Environmental.
The Base metric "represents the intrinsic and fundamental characteristics of a vulnerability that are constant over time and user environments." The Temporal and Environmental metrics are optional metrics that describe "the characteristics of a vulnerability that change over time" and "the characteristics of a vulnerability that are relevant and unique to a particular user's environment," respectively.
Typically, Temporal and Environmental metrics are calculated on a per-organization basis because these metrics may vary between each organization's environment. However, the Base metric alone is usually not accurate enough, so CERT/CC provides Temporal and Environmental metrics when we disclose vulnerabilities and consider some approximation of the entire internet as the environment.
Due to the characteristics of the BREACH vulnerability, namely its high-access complexity, the Base metric is 2.6, a 'minor' vulnerability in CVSS terms. Additionally, the Temporal metric lowers the score to 2.3 due to the relatively low threat (to our knowledge, BREACH is not currently "exploitable by functional mobile autonomous code") and the existence of a workaround (depending on how practical it is to disable HTTP compression).
If an attacker had all of the prerequisites needed to conduct a BREACH attack, namely a man-in-the-middle and a man-in-the-browser, the attacker would likely have access to a multitude of other easier (and arguably more damaging) attacks.
Determining severity with reasonable accuracy is an important input to vulnerability response activities such as patching and updating schedules, restricting network access, disabling vulnerable software components, and deploying exploit mitigation technologies. Focusing narrowly on specific, if interesting, aspects of a vulnerability can lead to a poor understanding of its severity, leading to misplaced effort or prioritization.