Two very interesting vulnerabilities got disclosed today, targeting OpenSSL and the SSL/TLS cryptography in general.
1. DROWN Attack
The first one is the one you should be aware of most urgently. It’s even got a marketing name and a fancy website, so you know it’s serious: the DROWN Attack.
DROWN stands for Decrypting RSA with Obsolete and Weakened eNcryption. I’m guessing they got the name and matching domain name first, then figured out the acronym.
Here’s how it works:
DROWN is a serious vulnerability that affects HTTPS and other services that rely on SSL and TLS, some of the essential cryptographic protocols for Internet security.
…
DROWN shows that merely supporting SSLv2 is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to a server that supports SSLv2 and uses the same private key.
In short: it’s a vulnerability targeting SSLv2.
Yes, SSLv2.
The same protocol you should have disabled on all your servers, appliances and configurations years ago, back when SSLv3’s POODLE vulnerability was disclosed.
If you have disabled SSLv2 and you’re thinking “I’m safe, right?", remember this: DROWN is made worse by its cross-protocol nature, i.e. an HTTPS server that doesn’t support SSLv2 may be vulnerable because it shares its public key with an SMTP server that does.
A single legacy, forgotten or unmanaged server that holds the private key to your SSL/TLS certificate is enough to compromise your security.
Disabling SSlv2 on your webservers
Just as a reminder, if you’re running Apache, here’s how to disable it:
SSLProtocol All -SSLv2 -SSLv3
Or on Nginx:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Honestly, if you’re vulnerable to DROWN, you probably had it coming by leaving this protocol enabled for so long.
Having said that: some unsuspecting systems could get you hacked because of this, especially:
- Mail servers with IMAPs and POPs (IMAP or POP3 over SSL) could still have old SSLv2 configurations
- Legacy servers or appliances that you forgot even had SSL enabled, by default they would support SSLv2
The DROWN fix by OpenSSL
OpenSSL has issued a new update to the OpenSSL codebase in a recent OpenSSL Security Advisory, stating:
NOTE: With this update, OpenSSL is disabling the SSLv2 protocol by default, as
well as removing SSLv2 EXPORT ciphers. We strongly advise against the use of
SSLv2 due not only to the issues described below, but to the other known
deficiencies in the protocol as described at
So it’s official: SSlv2 is out!
2. CacheBleed: A timing attack
As if one SSL related vulnerability isn’t enough, today is also the day CacheBleed got announced.
Their marketing budget was obviously smaller judging by the site, but they got a fancy name nonetheless.
Here’s the attack, summarised:
CacheBleed is a side-channel attack that exploits information leaks through cache-bank conflicts in Intel processors. By detecting cache-bank conflicts via minute timing variations, we are able to recover information about victim processes running on the same machine.
Our attack is able to recover both 2048-bit and 4096-bit RSA secret keys from OpenSSL 1.0.2f.
That last sentence bears repeating: Our attack is able to recover both 2048-bit and 4096-bit RSA secret keys. So long, security.
There’s only one, minor, upside to this CacheBleed deal:
OpenSSL has classified this vulnerability as “low severity”, which we agree with.
In order to mount the attack, the attacker has to be able to run the attack code on the same machine that runs the victim code. CacheBleed is a complex attack and there are much easier-to-exploit vulnerabilities in personal computers that it is unlikely that anyone would use CacheBleed in such an environment.
I’ve said it before and I’ll say it again: IT security is a myth.
One step forward, 3 prime steps back.