DROWN: Cross-protocol attack on TLS using SSLv2 (CVE-2016-0800)

Red Hat Product Security has been made aware of a vulnerability in the SSLv2 protocol, which has been assigned CVE-2016-0800 and is used in a cross-protocol attack referred to as DROWN - Decrypting RSA using Obsolete and Weakened eNcryption.

Overview

A group of security researchers discovered that SSLv2 (Secure Sockets Layer protocol version 2.0) is vulnerable to the Bleichenbacher RSA padding oracle attack, which can be used to decrypt RSA cipher text without the knowledge of the matching private RSA key. This can be done by observing responses from a server that has the private key and performs the decryption of attacker-provided cipher texts using that key. The researchers also demonstrated a new cross-protocol attack which allows decryption of SSL/TLS sessions using newer protocol versions - SSLv3 or any current TLS (Transport Layer Security) version (1.0 - 1.2) - using this SSLv2 weakness. This flaw is a SSLv2 protocol issue and affects all implementations of the protocol. Researchers refer to this attack as general DROWN.

Additionally, flaws were found in the SSLv2 protocol implementation in the OpenSSL cryptography and SSL/TLS library, which make it possible to perform a more efficient variant of the DROWN attack, referred to as special DROWN. These issues were assigned CVE-2016-0703 and CVE-2016-0704, and were already recently corrected as part of the fix for CVE-2015-0293.

Further details of this attack can be found in the researchers' paper titled DROWN: Breaking TLS using SSLv2.

Background

The SSLv2 protocol has known security issues and has been considered insecure since its replacement, SSLv3, was published in 1996. It was also formally deprecated in 2011 via RFC 6176. Its use on Internet today is limited, as modern SSL/TLS clients either do not support this protocol version at all, or use newer version whenever possible. However, many SSL/TLS servers still enable it. Such settings allow even very old clients to connect, and prior to the publication of the DROWN attack, there were no known threats to the security of connections from clients that support newer protocol versions.

Configurations affected by the DROWN attack

A server is vulnerable to the DROWN attack if it enables SSLv2 protocol in addition to SSLv3 or TLSv1.x, and if it uses RSA key exchange cipher suites. A server that does not enable SSLv2 can also be vulnerable if it shares its private RSA key with another server or service with SSLv2 enabled. For example, the DROWN attack can still be used to decrypt HTTPS sessions to a web server that does not enable SSLv2 if it shares its RSA key with, for example, an IMAP server, possibly running on the same host, that does enable SSLv2. Use of weak or export SSLv2 ciphers is required to efficiently perform the attack.

SSL/TLS connections using a non-RSA key exchange, such as Diffie-Hellman or Elliptic Curve Diffie-Hellman, can not be decrypted using the DROWN attack.

Attack description and impact

The DROWN attack described by the researchers consists of the following steps:

• An attacker first needs to record a certain number of SSL/TLS sessions between client and server using any version of the protocol and using RSA cipher suites. One of these recorded sessions will be decrypted. Researchers indicate that approximately 1,000 sessions are sufficient for the attack.

• Subsequently, the attacker opens many SSLv2 connections to the server. For some of these connections, the attacker needs to brute force a 40-bit (if one of the SSLv2 EXPORT ciphers can be used) or a 56-bit (for cipher suite using DES) session key. Researchers estimate that approximately 40,000 connections are needed.

• After that, the attacker is able to decrypt "premaster secret" data from one of the originally recorded handshakes. That data is used to generate symmetric session keys, and hence decrypt the whole recorded SSL/TLS session. Additional sensitive data can be obtained form the decrypted session, such as authentication credentials or cookies.

Researchers indicate they were able to decrypt a TLS 1.2 handshake with a server using 2048 bit RSA keys using 1,000 recorded handshakes, 40,000 SSLv2 connections, and 2⁵⁰ offline computations. Their attack took less than 8 hours using resources of a public cloud provider at a cost of 440 USD.

They also indicate that the use of the special DROWN attack reduces the number of SSLv2 connections down to 14,000 and can be performed using a single workstation in less than 3 minutes. That makes it possible to use this flaw to perform an active man-in-the-middle (MITM) attack and impersonate a TLS server to connecting TLS client.

SSL and TLS libraries with SSLv2 support

Red Hat products include the following components that implement support for SSLv2 protocol. That support may be enabled based on how applications use these SSL/TLS libraries.

SSLv2 in OpenSSL

Applications using OpenSSL have to select a connection method to inform the library which SSL/TLS protocol versions they want to use. OpenSSL connection methods either enable a single protocol version, or the special method SSLv23 can be used to enable all protocol versions supported by the library. This is the most commonly used connection method. The SSLv2 protocol is automatically enabled when this method is selected. Applications have to explicitly set the SSL_OP_NO_SSLv2 option in the relevant SSL_CTX or SSL objects to disable SSLv2. While many applications do that, either unconditionally or based on their configuration, other applications use the default set of enabled protocols. Applications using the OpenSSL library are therefore likely to run with SSLv2 enabled.

The following changes were applied to OpenSSL included in Red Hat products to address this issue:

• The SSLv2 protocol is no longer enabled by default when using the SSLv23 connection method.
• All SSLv2 cipher suites using 40 bit (EXPORT) or 56 bit (single DES) symmetric encryption keys are now disabled and can no longer be used. The following cipher suites are no longer available:
  • EXP-RC2-CBC-MD5 / SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5
  • EXP-RC4-MD5 / SSL_CK_RC4_128_EXPORT40_WITH_MD5
  • DES-CBC-MD5 / SSL_CK_DES_64_CBC_WITH_MD5
• The OpenSSL versions in the openssl packages in all updates for Red Hat Enterprise Linux 4 and 5 now check the OPENSSL_ENABLE_SSL2 environment variable and if it is defined, SSLv2 is enabled by default when using the SSLv23 connection method. This environment variable can be used to re-enable SSLv2 if needed.

The SSLv2 connection method is not affected by the change to the SSLv23 connection method and can still be used to establish connections using SSLv2 protocol.

Also note that while the DEFAULT cipher list in OpenSSL versions as shipped in Red Hat Enterprise Linux 6 and 7 excludes all SSLv2 cipher suites, this default does not prevent servers from accepting SSLv2 connections from clients that force the use of a disabled cipher suite. This issue was assigned CVE-2015-3197 and is also fixed in updates that address the DROWN issue.

SSLv2 in NSS (Network Security Services)

The NSS cryptography library implements the SSLv2 protocol, but it does not enable it by default. Applications need to explicitly ask the library to enable SSLv2 to use it. The NSS versions shipped with Red Hat Enterprise Linux 7 do not allow enabling SSLv2 protocol at all. Applications using the NSS library are unlikely to run with SSLv2 enabled.

As the NSS library does not enable SSLv2 by default, no immediate updates are planned to address the DROWN issue. Future updates in Red Hat Enterprise Linux 6 are expected to disable the protocol in a similar way to how it is disabled in Red Hat Enterprise Linux 7.

SSL and TLS libraries without SSLv2 support

Red Hat products include the following components that implement some TLS or SSL protocol version, but do not implement support for SSLv2. Therefore, these components are not affected by this issue. Note that applications using these unaffected libraries may still be affected by the DROWN attack if they share their private RSA key with another application that uses an SSL/TLS library that supports SSLv2.

• GnuTLS
• OpenJDK (packages java-1.6.0-openjdk, java-1.7.0-openjdk, java-1.8.0-openjdk)
• Oracle JDK (packages java-1.6.0-sun, java-1.7.0-oracle, java-1.8.0-oracle)
• IBM JDK (packages java-1.6.0-ibm, java-1.7.0-ibm, java-1.7.1-ibm, java-1.8.0-ibm)

Resolution

Red Hat recommends that customers conduct a risk-based prioritization analysis of their affected systems and immediately apply available patches to remediate the issue. Rebooting the system after updating is the safest way to ensure all affected services use the updated OpenSSL library. If a reboot is not possible, restarting all network services that depend OpenSSL after applying the patches is required.

Product	Package	Advisory
Red Hat Enterprise Linux 4 Extended Lifecycle Support	openssl-0.9.7a-43.23.el4	RHSA-2016:0306
Red Hat Enterprise Linux 5	openssl-0.9.8e-39.el5_11	RHSA-2016:0302
Red Hat Enterprise Linux 5.6 Long Life	openssl-0.9.8e-12.el5_6.13	RHSA-2016:0304
Red Hat Enterprise Linux 5.9 Long Life	openssl-0.9.8e-26.el5_9.5	RHSA-2016:0304
Red Hat Enterprise Linux 6	openssl-1.0.1e-42.el6_7.4	RHSA-2016:0301
Red Hat Enterprise Linux 6.2 Advanced Update Support	openssl-1.0.0-20.el6_2.8	RHSA-2016:0303
Red Hat Enterprise Linux 6.4 Advanced Update Support	openssl-1.0.0-27.el6_4.5	RHSA-2016:0303
Red Hat Enterprise Linux 6.5 Advanced Update Support	openssl-1.0.1e-16.el6_5.16	RHSA-2016:0303
Red Hat Enterprise Linux 6.6 Extended Update Support	openssl-1.0.1e-30.el6_6.12	RHSA-2016:0305
Red Hat Enterprise Linux 7	openssl-1.0.1e-51.el7_2.4	RHSA-2016:0301
Red Hat Enterprise Linux 7.1 Extended Update Support	openssl-1.0.1e-42.el7_1.10, openssl-1.0.1e-42.ael7b_1.10	RHSA-2016:0305
Red Hat Enterprise Linux 6	openssl098e-0.9.8e-20.el6_7.1	RHSA-2016:0372
Red Hat Enterprise Linux 7	openssl098e-0.9.8e-29.el7_2.3	RHSA-2016:0372
Red Hat JBoss Web Server 2.1	openssl	RHSA-2016-0445
Red Hat JBoss Web Server 3.0.2	openssl	RHSA-2016-0446
Red Hat JBoss Enterprise Application Platform 5.2	openssl	Apply RHEL OS Patch; Patch Pending for Windows & Solaris
Red Hat JBoss Enterprise Application Platform 6.4	openssl	Apply RHEL OS Patch; Patch Pending for Windows & Solaris

Acknowledgements

Red Hat would like to thank the OpenSSL project for reporting these issues. Upstream acknowledges Nimrod Aviram and Sebastian Schinzel as the original reporters.

Frequently Asked Questions

How to disable SSLv2 in application X?

Refer to the knowledge base article Securing Application 'X' in RHEL 'Y' ? for information on how to change SSL/TLS related settings, such as enabled protocol versions, in various applications shipped with various Red Hat Enterprise Linux versions.

Do server keys or certificates need to be regenerated because of this issue?

No. DROWN does not directly expose private RSA keys, but targets individual session keys which are generated during SSL/TLS connection handshakes and used for the symmetric encryption. Compromise of those keys allows decryption of specific SSL/TLS sessions. As such, even if a service is detected as vulnerable to DROWN attack, there is no need to regenerate service key or certificate.

Is SSLv2 enabled in the versions of the Apache httpd web server shipped with Red Hat products?

The Apache httpd web server can use one of the following modules to provide HTTPS service:

• mod_ssl - This module uses the OpenSSL cryptographic library and is included as part of the Apache httpd web server distribution.
• mod_nss - This module uses the NSS cryptographic library and is developed and distributed separate from the Apache httpd project.

Both of these modules are included in Red Hat products.

The default settings for httpd using mod_ssl are:

• The httpd versions shipped with Red Hat Enterprise Linux 7, in the httpd24 collection in Red Hat Software Collections and with Red Hat JBoss Web Server 3, are based on upstream httpd version 2.4 and they can not be configured to enable SSLv2 protocol.

• The httpd versions shipped with Red Hat Enterprise Linux 5 and 6, Red Hat JBoss Web Server 1 and 2, and Red Hat JBoss Enterprise Application Platform 6 are based on upstream httpd versions 2.2. Those versions can be configured to use SSLv2, however that protocol is disabled in the default configuration. The /etc/httpd/conf.d/ssl.conf configuration file includes the following configuration directive that disables SSLv2:

SSLProtocol all -SSLv2

• The httpd versions shipped with Red Hat Enterprise Linux 4 are based on upstream httpd versions 2.0. The default configuration enables SSLv2, which can be disabled by adding the same SSLProtocol directive as listed above to the /etc/httpd/conf.d/ssl.conf configuration file and restarting the httpd service.

The default settings for httpd using mod_nss are:

• The mod_nss versions shipped with Red Hat Enterprise Linux 5, 6, and 7 do not enable SSLv2 by default. The /etc/httpd/conf.d/nss.conf configuration file includes, depending on the mod_nss package version, one of the following configuration directives that only enable SSLv3 or later, or TLSv1.0 or later:

NSSProtocol SSLv3,TLSv1
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

NOTE: Because of known SSLv3 protocol issues, we continue to recommend that the version is also disabled. See related POODLE: SSLv3 vulnerability (CVE-2014-3566) article for details and instruction on how to disable SSLv3 protocol in various components of Red Hat products.

Is SSLv2 enabled in the mail SMTP servers shipped with Red Hat Enterprise Linux?

Default configurations of both Postfix and Sendmail mail servers in Red Hat Enterprise Linux 5, 6, and 7 do not enable SSL/TLS encryption.

If a system administrator enables SSL/TLS in Postfix, SSLv2 is enabled with opportunistic encryption and disabled with mandatory encryption by default. In Red Hat Enterprise Linux 6 and 7, it is possible to disable SSLv2 with opportunistic encryption using the smtpd_tls_protocols configuration option.

If a system administrator enables SSL/TLS in Sendmail, SSLv2 is enabled enabled by default. In Red Hat Enterprise Linux 5, 6, and 7, it is possible to disable SSLv2 using the ServerSSLOptions configuration option.

See question "How to disable SSLv2 in application X?" above for links to further resources on how to configure SSL/TLS in Postfix and Sendmail.

Do I need to update my Red Hat JBoss Enterprise Application Platform 5.x and 6.x installations?

The JBossWeb component of the JBoss Enterprise Application Platform can be configured to use the Java-based HTTPS connectors that use Java cryptography provider (JSSE), or the APR/native HTTPS connectors that use the OpenSSL library as the cryptography provider.

JBoss Enterprise Application Platform 6.4 has been tested on Microsoft Windows using APR/OpenSSL connectors and although technically the OpenSSL library requires an update, JBoss Enterprise Application Platform 6.4 only enables TLSv1.0 and newer by default, and rejects SSLv2 and SSLv3 protocol connections. JBoss Enterprise Application Platform 6.4 is not currently expected to be vulnerable to this flaw.

JBoss Enterprise Application Platform 5.2 is being tested on Microsoft Windows to assess vulnerability to this to this flaw.

The httpd component of the JBoss Enterprise Application Platform 6.x can be configured to accept HTTPS connections using the mod_ssl module. See the Is SSLv2 enabled in the versions of the Apache httpd web server shipped with Red Hat products? FAQ entry above for further details of its default configuration.

If you are using the APR/OpenSSL connectors with JBossWeb, or httpd with mod_ssl, then you should take the following steps:

• JBoss Enterprise Application Platform installed on Red Hat Enterprise Linux - Upgrade system OpenSSL packages.
• JBoss Enterprise Application Platform installed on Microsoft Windows or Oracle Solaris - An update for the OpenSSL libraries distributed with JBoss Enterprise Application Platform will be available on the Red Hat Customer Portal.

Do I need to update my Red Hat JBoss Web Server 2.x and 3.x installations?

Tomcat components of the JBoss Web Server can be configured to use the Java-based HTTPS connectors that use Java cryptography provider (JSSE), or the APR/native HTTPS connectors that use the OpenSSL library as the cryptography provider. In the current versions, APR/OpenSSL connectors only enable SSLv3 or newer (JBoss Web Server 2.1.0), or TLSv1 or newer (JBoss Web Server 3.0.2) protocols by default. Future JBoss Web Server 3 versions are expected to remove SSLv2 and SSLv3 support.

The httpd component of the JBoss Web Server can be configured to accept HTTPS connections using the mod_ssl module. See the Is SSLv2 enabled in the versions of the Apache httpd web server shipped with Red Hat products? FAQ entry above for further details of its default configuration.

If you are using the APR/OpenSSL connectors with Tomcat, or httpd with mod_ssl, then you should take the following steps:

• JBoss Web Server installed on Red Hat Enterprise Linux - Upgrade system OpenSSL packages.
• JBoss Web Server installed on Microsoft Windows or Oracle Solaris - An update for the OpenSSL libraries distributed with JBoss Web Server will be available on the Red Hat Customer Portal.

Do I need to update my Fuse, or A-MQ installation?

See the Disabling SSLv2 in JBoss Fuse 6.x and JBoss A-MQ 6.x article for more details about those products.