• United States




OpenSSL update fixes DROWN vulnerability

Mar 01, 20165 mins
NetworkingOpen SourceSecurity

The DROWN attack decrypts TLS sessions on servers supporting SSL v2 and using RSA key exchange

An international team of researchers has uncovered an attack that can compromise encrypted network traffic in a matter of hours.

The DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) attack successfully decrypts TLS (transport layer security) sessions by exploiting a vulnerability in the older SSL v2 protocol that exposes private RSA keys. Once again, old cryptography is breaking the security of all online communications.

DROWN is different from other attacks against TLS in that it doesn’t need servers to be using the older version; the attack will succeed as long as the targeted system supports SSL v2. The cross-protocol attack (CVE-2016-0800) could lead to decryption of any encrypted session using SSL/TLS protocols as long as the server supports SSL v2 and uses RSA key exchange, the researchers said in their technical paper.

By making repeated SSL v2 connection requests, researchers uncovered bits of information about the server’s private RSA key. After enough requests, researchers were able to obtain the private key to decode the TLS sessions. The attack scope widens if the organization reuses that private RSA key across servers, even if different certificates are used.

SSL v2, released in 1995 and retired less than a year later due to crippling weaknesses, is old enough that it is unlikely anyone is still using this version. Browsers and email clients don’t support SSL v2, but many servers and networking devices do. If a computer specifically requested to establish a SSL v2 session, those servers would switch to the vulnerable protocol instead of using the default, and more secure, TLS.

“For many years, the argument for not disabling SSL v2 was that there was no harm because no browsers used it anyway,” said Ivan Ristic, director of engineering at Qualys. 

DROWN illustrates the folly of that thinking, since obsolete cryptography can be dangerous even if it isn’t actively being used. All administrators need to immediately disable SSL v2 on all their servers.

The attack is made worse by two additional implementation vulnerabilities in OpenSSL, prompting the project team to release versions 1.0.2g and 1.0.1s to address the issues.

The issue with OpenSSL

OpenSSL versions 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze, and earlier have a vulnerability that makes it easier to run a cheaper and more efficient version of DROWN (CVE 2016-0703 and CVE 2016-0704). In the general attack scenario, the attacker targeting a vulnerable server would need to observe 1,000 TLS handshakes, initiate 40,000 SSLv2 connections, and perform 250 offline work to decrypt a 2048-bit RSA TLS cipher-text. On systems running vulnerable versions of OpenSSL, the attacker can obtain a key for one out of 260 TLS connections after running about 17,000 probe connections. The computation takes less than a minute on a fast PC.

“If the conditions are right, the same SSL v2 flaw can be used for real-time MITM attacks and even against servers that don’t support the RSA key exchange at all,” Ristic said.

OpenSSL versions 1.0.2a, 1.0.1m, 1.0.0r, and 0.9.8zf released in March 2015 and later are not vulnerable to this efficient version of the DROWN attack. The March 2015 update had refactored the code containing the vulnerability in order to fix a different flaw (CVE 2015-0293), and thus had closed the avenue of attack.

In the latest update, OpenSSL disabled the SSL v2 protocol by default and removed SSL v2 EXPORT ciphers. Administrators are urged to update vulnerable versions of OpenSSL as soon as possible.

“Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS servers, if they’ve not done so already,” the OpenSSL project team wrote in its security advisory.

Details on the OpenSSL update

According to the OpenSSL advisory, there are some caveats for servers running vulnerable versions of OpenSSL. For servers running OpenSSL 1.0.1r or 1.0.2f or later, just disabling all SSLv2 ciphers is sufficient. For older versions, disabling the ciphers won’t be enough because malicious clients can force the server to use SSL v2 using EXPORT ciphers. In those cases, SSL v2 must be disabled as well.

The latest version of OpenSSL, 1.0.2g and 1.0.1s, disables SSL v2 at build-time by default. To enable SSL v2, the builds must be manually configured with “enable-ssl2.” Even if the the build is manually configured with SSL v2, it will still have to make explicit calls to make it even more difficult to request SSL v2 sessions. The SSLv2 40-bit EXPORT ciphers and SSLv2 56-bit DES are no longer available. Weak ciphers in SSLv3 and up are also disabled.

The OpenSSL update also addressed five other low severity vulnerabilities: a double-free bug (CVE 2016-0705) that could lead to a denial-of-service attack or memory corruption for applications receiving DSA private keys from untrusted sources; a memory leak in SRP database lookup method SRP_VBASE_get_by_user (CVE-2016-0798); a side channel attack that makes use of cache-bank conflicts on the Intel Sandy-Bridge microarchitecture (CVE 2016-0702); memory issues in BIO_*printf functions (CVE 2016-0799); and a null pointer deref/heap corruption in the BN_hex2bn function (CVE 2016 0797).

The side-channel attack was reported by the same team of researchers who uncovered DROWN. This attack could also lead to the recovery of RSA keys, but the ability to exploit the attack was “limited as it relies on an attacker who has control of code in a thread running on the same hyper-threaded core ad the victim threat which is performing decryptions,” the advisory said.

There is a tendency to keep older versions of technology around just-in-case, just in case someone needs to use it, just in case a process relies on it. The thinking that as long as it’s not used by default, (or by browsers) is putting the security of online communications at risk. DROWN joins the ranks of the previously discovered Logjam and FREAK in showing that even obsolete protocols can be abused.

“In the future we must ensure that all obsolete crypto is aggressively removed from all systems. If it’s not, it’s going to come back to bite us, sooner or later,” Ristic said.


Fahmida Y. Rashid is a freelance writer who wrote for CSO and focused on information security. Before joining CSO, she wrote about networking and security for various technology publications, including InfoWorld, eWeek, PC Magazine, Dark Reading, and CRN. She also spent years as an IT administrator, software developer, and data analyst. "I, for one, welcome our new computer overlords."

More from this author