You’re probably aware that the OpenSSL team disclosed a “high severity” vulnerability earlier today. You’re probably aware, because the internet has been buzzing with anticipation, hype and fear that this was a new heartbleed.
Disclosing vulnerabilities
The OpenSSL team announced the upcoming patch of the vulnerability several days in advanced. It followed its security policy. I’m 100% in favor of this.
However, the current state of the OpenSSL security policy – and other open source projects as well – have a limited description of these severities.
For instance, the OpenSSL team has categorised this vulnerability as a high severity issue according to this description:
high severity issues: this includes issues affecting common configurations which are also likely to be exploitable. Examples include a server DoS, a significant leak of server memory, and remote code execution.
According to the above definition, this was indeed a high severity vulnerability. It was likely to be exploitable, given the latest release of the OpenSSL codebase.
However, hardly anyone uses the latest release of OpenSSL.
Hyping Security Disclosures
The Heartbleed vulnerability got the same severity as the one from last night. Heartbleed was a disaster, CVE-2015-1793 will probably go by unnoticed. It won’t get a logo. It won’t get a website. It won’t get its own themesong.
Why? Because CVE-2015-1793, no matter how dangerous it was in theory, concerned code that only a very small portion of the OpenSSL users were using.
But pretty much every major technology site jumped on the OpenSSL advisory. Doomsdays scenarios were being created and hyped. It could be the next Heartbleed! What if it’s a new Logjam? The Internet is doomed!
- The Inquierer: High severity bug found in OpenSSL raises fears of another Heartbleed
- Slashdot: ‘Severe Bug’ To Be Patched In OpenSSL
- The Hacker News: OpenSSL to Patch Undisclosed High Severity Vulnerability this Thursday
- …
At this rate, the tech industry will actually become the boy who cried wolf.
Attention-seeking headlines draw more pageviews, more clicks and ultimately more revenue. It’s all the fault of online advertising.
Adding context to announcements
The announcement of forthcoming security releases were vague with details. That’s obviously intentional.
The OpenSSL team is in a particularly tricky situation, though. On the one hand, their advisories are meant to warn people without giving away the real vulnerability. It’s a warning sign, so everyone can keep resources at hand for quick patching, should it be needed.
At the same time, they need to warn their users of the actual severity. Publishing false advisories discredits them entirely 1.
And while the OpenSSL team can make an educated guess as to which versions of the library are most used, they cannot know for sure. If some company is embedding OpenSSL onto their devices and kept it all quiet, this recent vulnerability may have been a disaster for them.
So what’s there to do?
Client/Server, Affected installs, Likelihood of exploit
Here’s the part where it gets very dangerous. I’m about to make suggestions on what additional information could be safely disclosed, without giving away the actual vulnerability.
There may just be a practical limit here, where it’s absolutely not feasible to do. In which case, it’s probably just best to stick to the current security policy, vague as it is, and let the internet regulate themselves.
Depending on your work or interest area, you may be more suspicious of server than client vulnerabilities. Heartbleed was an obvious server nightmare, whereas CVE-2015-1793 only affects the client-side of applications 2. At the same time, if the vulnerable version of OpenSSL was used in web browsers, it would have been a disaster nonetheless.
Open question #1: should the announcement mention if it’s a client- or server side bug?
A lot of Linux distributions and applications (Apache2, Nginx, OpenSSH) use OpenSSL. This is publicly known. The OpenSSL crew is undoubtably aware of this. This puts them in a position to take into account the install-base of the openssl libraries whose code is vulnerable.
A vulnerability in openssl 1.0.1e (Red Hat 6.x and 7.x) or 0.9.8e (Red Hat 5.x) is going to be a lot more severe than a vulnerability in code that was just released a month ago and hasn’t been adopted by distributions yet.
Open question #2: should the announcement mention the potential impacted installations?
Both questions play a vital role in determining the actual severity of a vulnerability. Yet at the same time, an advisory cannot tell exactly which versions will be affected nor can it describe the platforms that will need to install patches, since it risks giving away too much information for anyone out looking for the bug.
I’m not sure if there is a proper solution to this problem, but I’m hoping the next security advisory – wether it’s from OpenSSL, Xen, Red Hat or any other player out there – does whatever it can to make the actual severity as clear as possible.
Doing so would reduce unnecessary hype and fear and could eventually spare a lot of (human) resources from being unnecessarily scheduled or reserved.
1 Don’t let this get into a flame war of LibreSSL vs OpenSSL vs BoringSSL, please. ;-)
2 ‘Client’ is used in the broad sense, since any web application can consume an SSL/TLS stream or endpoint and act as a client on its own.