If you have anything to do with web security, like we do, you’ve probably been in “bated breath” mode this week.
That’s because the OpenSSL team announced, on Monday 2015-07-06, that it had a “high severity” update coming out in three days’ time, meaning today, Thursday 2015-07-09:
The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p.
These releases will be made available on 9th July. They will fix a single security defect classified as "high" severity. This defect does not affect the 1.0.0 or 0.9.8 releases.
And that’s all she wrote.
What is OpenSSL?
OpenSSL is a very widely used internet security toolkit that implements a cryptographic security protocol called TLS/SSL, and puts the “S” in HTTPS for a great many websites.
OpenSSL is also widely known because of the Heartbleed vulnerability, uncovered in 2014.
Heartbleed meant that almost anyone with an internet connection could suck secret data out of your servers at will, without actually needing to break in or even to do any sort of hacking.
To trigger the Heartbleed bug, you merely asked the server to send you a so-called keep-alive message.
A keep-alive system is an uncontroversial feature that many internet protocols support, because keeping an existing connection going is a lot less complicated than starting a new one.
Keep-alives are a bit like those short conversations about not very much that you have every now and then when you’re travelling in a car at night, just to make sure the driver’s still alert.
The Heartbleed problem was that you could ask the server to send you a keep-alive response that was much larger than the memory buffer it was using to process your keep-alive message, and it would happily oblige.
So, you’d receive a reply that included your message, followed by random extra stuff out of server memory that you weren’t supposed to see.
Most of it would be harmless, but every now and then you might get hold of snippets of other people’s traffic, passwords, encryption keys, and more.
Waiting for the fix
These historical facts – the prevalence of OpenSSL and bad memories of Heartbleed – meant that OpenSSL’s terse email notification on Monday wasn’t very comforting.
Why an update just for a single security hole? How “high” was the high severity?
Was this going to be a denial-of-service bug? Or would it be a data leakage hole, like Heartbleed?
Or a full-on remote code execution flaw that would allow outsiders to run commands on your server as if they were actually logged in to your network?
More specifically, would all sub-versions of OpenSSL in the 1.0.1 and 1.0.2 series be at risk, or would some releases turn out to be OK?
How to prepare for what was coming on Thursday?
The flaw
The update is out, and our verdict is that the bug isn’t as bad or as widespread as we feared at first.
Nevertheless, if you’re vulnerable, you need to act.
Simply explained, CVE-2015-1793 is a certificate verification flaw.
This means that crooks who can lure or misdirect you to a bogus website (or email server, or indeed any internet service using TLS/SSL for its security) may be able trick you into thinking that you are somewhere legitimate and secure.
As you probably know, TLS/SSL relies on a “chain of trust” formed by cryptographic certificates.
This chain of certificates reassures you that the secure website you are visiting really does belong to the organisation you expect.
Here’s an example we’ve used before, based on Naked Security itself:
Naked Security’s certificate is owned by Sophos; Sophos’s right to represent itself as Naked Security is vouched for by GlobalSign; and GlobalSign’s right to vouch for Sophos is vouched for by Firefox.
If crooks created their own certificate claiming to be Sophos, and used it to vouch for a fake version of Naked Security, they’d almost certainly come unstuck.
Your browser would complain: the certificate presented by the crooks wouldn’t be vouched for by any trusted certificate authority (CA).
You’d see a warning like this:
→ Wrongly-signed certificates do turn up from time to time, and can cause serious security problems. Bad certificates are often down to an insecure, venal or incompetent CA. CAs who don’t take security seriously are usually thrown out by the major browser makers, thus effectively cancelling all certificates they’ve signed. The errant CA will be expected to show strong reasons before it will be trusted again.
Effects of the bug
This latest bug in OpenSSL means that a crook may be able to create a certificate in someone else’s name, and then to sneak it past OpenSSL’s certificate verifcation process without triggering a warning, even though the certificate isn’t signed by a trusted CA.
That makes a man-in-the-middle (MiTM) attack feasible, where a crook intercepts your traffic, say to a social networking site; feeds you a fake login page with a fake HTTPS certificate; and convinces you to give away your password because the warnings that ought to prevent the phishing deception never show up.
How big is the risk?
Fortunately, the scope of this bug is narrower than we feared after reading Monday’s OpenSSL advisory.
First, this bug doesn’t give cybercrooks the ability to steal data or break into your servers directly, because:
- Crooks can’t bleed confidential data from your server at will, as with Heartbleed.
- Crooks can’t sniff (record) arbitrary network traffic and crack the TLS encryption later.
- Crooks can’t send malformed data packets and break into your web, email, or other OpenSSL-protected servers.
Second, only four of the many officially-supported OpenSSL versions are affected:
- Versions 1.0.2b and 1.0.2c need updating to 1.0.2d. (The -a sub-version is immune.)
- Versions 1.0.1n and 1.0.1o need updating to 1.0.1p. (Sub-versions up to and including -m are immune.)
- All 0.9.8 versions are immune.
- All 1..0 versions are immune.
Third, most servers (unless they connect to other servers, or do reverse certificate verification of clients, which is rare) are not affected, because this certificate trickery affects the client that is connecting, not the server it is connecting to.
Fourth, all the Big Four web browsers – Internet Explorer, Firefox, Safari and Chrome – do not use OpenSSL and are therefore immune.
What to do?
Many products other than web browsers, including software updaters, RSS feed readers, scripting tools and email clients, not only use TLS/SSL but may include code from OpenSSL.
These may need updating.
If you aren’t sure, ask the maintainers (for open source products) or your vendor (for commercial software) to tell you whether they use OpenSSL, and whether the products needs updating.
What about Sophos products?
The good news is that Sophos products are not at risk from this bug.
Only the current pre-release version of Sophos Management Communication System (MCS 3.0.0 Beta) includes an affected version of OpenSSL.
However, MCS 3 Beta does not rely on the buggy part of the OpenSSL code for certificate verification, so cannot fall foul of the bug. (Nevertheless, we expect to update MCS 3 Beta with the latest OpenSSL version by mid-August 2015.)
All other Sophos product families either don’t use OpenSSL at all, or use one of the unaffected versions.