This week’s cute OpenSSL vulnerability is CVE-2015-1793. This little one-line OpenSSL bug could allow an attacker who has a legitimate end-leaf certificate to circumvent the OpenSSL code that validates the certificate’s purpose. The attacker could then, in theory, sign other leaf certificates and use those to pull off a man-in-the-middle attack on SSL sessions. The bug was slapped with the name “OprahSSL” because everyone gets to become a certificate authority. We all had a good laugh about this; someone even made a twitter account and a logo.
We in the security community have really started to hit our stride when it comes to naming and shaming cryptographic vulnerabilities. Let’s have a golf clap for social media awareness campaigns about crypto vulnerabilities. Good job, everyone.
Kidding aside, exactly how serious was OprahSSL? How did it compare the parade of other cleverly-named SSL vulnerabilities of the last four years? People remember BREACH and BEAST and Heartbleed and LOGJAM, to name a few. How did OprahSSL compare to them?
According to the Common Vulnerability Scoring System (CVSS) scores, OprahSSL was worse than Heartbleed.
OprahSSL: 6.4 Base Score, 10.0 exploitability
Heartbleed: 5.0 Base Score, 10.0 exploitability
In my opinion, Heartbleed was the most heinous crypto vulnerability of all time, so this doesn’t pass the sniff test. I think CVSS is scoring incorrectly in this case. Maybe because CVSS has to cover too many threat surfaces, so the resulting scores for SSL vulnerabilities are overly broad and seem out of context.
CVSS is all well and good, but I’ve been thinking about an SSL vulnerability scoring system specifically for the enterprise administrator. Such a system could be a reference for discussing the severity of new vulnerabilities like OprahSSL and slot them into a stack rank. Using the enterprise specifically as the context for SSL, we can turn value judgments into metrics. For example, we might decide that server vulnerabilities are worse than client vulnerabilities. The former means we have to patch something to protect corporate assets. The latter means that browsers will invisibly update their client software and we can go back to playing Minecraft—I mean, migrating firewall rulesets.
To stack rank SSL vulnerabilities for the enterprise, we can quantify the potential impact of a vulnerability by looking at the assets in play. In the table below, higher number values are associated with higher value targets.
Most SSL vulnerabilities (CRIME, TIME, BEAST, BREACH, POODLE) are oracle attacks, meaning that they tease information out of the encrypted text one byte at a time. Often they require software running inside the browser (so-called “man-in-the-browser”) coupled with software that can see and or modify data in-transit (man-in-the-middle). Some exploits require only one of these two (MitB or MitM) and others require both of these as well as millions of messages (MMM) from which they can tease out information.
Exploits that require any or all of these (MitB, MitM, MMM) should not be considered as exploitable as exploits that do not require these fancy setups. Therefore, we can create a table of exploitability like this:
If an attacker must get malicious software into your browser to generate millions of messages so that they can then run cryptanalysis on the resulting ciphertext, then the attacker is really just writing a boutique academic paper. In real life, it would be far easier to just have the malicious software steal whatever the attacker is looking for, such as user credentials.
So, now that we have both Impact and Exploitability ratings, we can generate metrics for their severity for enterprise administrators. If we multiply the maximum values of 10 and 10 (for Impact and Exploitability), we get a maximum of 100. Let’s give the ranges some names:
Impact*Exploitability Naming Structure
Score Range | Level Name
1-33 – Hello Kitty
34-66 – Bowser
67-100 – Godzilla
And let’s apply our impacts and exploitability matrix to the raft of SSL vulnerabilities since 2011’s BEAST attack.
So there you have it. Heartbleed retains its crown as the worst SSL vulnerability, and Early CCS (ChangeCipherSpec) comes in second. Surprisingly, OprahSSL comes in third, yet with a score exactly half of Early CCS, it’s ranked only as a Bowser-level vulnerability.
And it likely won’t ever see much exposure on the Internet since it was caught so quickly after it was introduced.
The majority of SSL vulnerabilities (at the Hello Kitty level) require thousands or millions of messages and an agent inside the browser. These “boutique” vulnerabilities often don’t have any exploit tools (although sometimes tests). Sure, we have to keep patching them because, well, that’s part of our job.
I intend to maintain this list of SSL vulnerabilities, stack-ranked for the enterprise. As new SSL vulnerabilities surface, we can use our enterprise-specific categorization to decide if it’s going to be a Godzilla day or a Hello Kitty day.
I’m betting it won’t be long before we can run this exercise again.