DROWN Vulnerability: A Breakdown of the Threat and How to Avoid the Next One

Featured article by Randy Kilmon, VP, Engineering at Black Duck

Understanding open source vulnerabilities is a daunting challenge. Most companies do not have a good handle on where open source software is being used across their organizations. As a result, when vulnerabilities in open source (e.g., Heartbleed, Shellshock, Ghost, Freak and now DROWN) come to light, companies are not able to quickly assess their exposure and take action to remediate that exposure.

Open source software seeps into a company’s code base from many different sources, both internally and externally. The benefits of open source software — lower development costs, faster time to market, more robust features — have led to a dramatic increase in its use over the last 10 years to the point where it now accounts for about a third of the code in use across the Fortune 500. The downside of this growth is that typically there are few, if any, tracking mechanisms in place to provide an inventory of all the open source software being used within a company.

The DROWN vulnerability, which international researchers warned on March 1^st could impact 11 million websites, is the latest in a very long list of security holes associated with the SSL2.0 protocol. SSL is NOT an encryption format, rather, it’s a protocol for negotiating the type of encryption used to establish a secure connection over the network. Through this process, client and server will “agree” to a mutually supportable encryption cypher.

SSL2 is fundamentally insecure in that it does the “handshake” over an unencrypted connection and without authentication. A “man in the middle” can force “agreement” to a very weak cypher rather than a very strong one. This flaw was initially reported in 1996 and was subsequently fixed in SSLv3. No modern browsers support SSLv2 by default.

Problem solved, right?  Not quite. Servers that have not disabled the SSLv2 protocol, and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2 ciphers are nominally disabled, because malicious clients can force the use of SSLv2 with EXPORT ciphers.

Users can avoid DROWN by disabling the SSLv2 protocol in all their SSL/TLS servers (if they’ve not done so already). Disabling all SSLv2 ciphers is also sufficient if the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and 1.0.2f) have been deployed.

Looking forward, as more and more devices join the Internet of Things (e.g., cars, thermostats, refrigerators, etc.) the risk of vulnerabilities such as DROWN grows, as does the logistical problem of tracking all the open source components and versions that are out there. It is essential that open source communities and the companies that use open source develop a plan for proactively finding vulnerabilities, quickly fixing them and having a way to patch the software that is already in use.