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

Impacted Products

This issue has been rated as having Important impact by Red Hat Product Security.

The following Red Hat Product versions are impacted:

• Red Hat Enterprise Linux 4*
• Red Hat Enterprise Linux 5
• Red Hat Enterprise Linux 6
• Red Hat Enterprise Linux 7
• Red Hat JBoss Enterprise Web Server 2.1.0 (See FAQ below)
• Red Hat JBoss Enterprise Web Server 3.0 (See FAQ below)
• Red Hat JBoss Enterprise Application Platform 5.2 (See FAQ below)
• Red Hat JBoss Enterprise Application Platform 6.4 (See FAQ below)

All versions of NSS shipped with Red Hat Enterprise Linux 5, 6, and 7 are not affected by this vulnerability.

*An active ELS subscription is required for access to this patch in RHEL 4. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

What is the Red Hat Enterprise Linux Extended Life Cycle Support Add-On (ELS)?

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 )

Frequently Asked Questions

Is SSLv2 enabled in the versions of 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 OpenSSL cryptographic library and is included as part of the Apache httpd web server distribution.
• mod_nss - This module uses 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 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

																																																					

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.

• Red Hat Enterprise Linux

  • Upgrade OpenSSL for your version. (see the Resolve Tab of this article for RHSAs)

  • Windows or Solaris

    • An update for the openssl libraries will be available on the Customer Service Platform. This update will replace the libssl and libeay libraries and openssl application.

EAP 6.4 has been tested on Windows using APR/OpenSSL and although technically the OpenSSL library requires an update, EAP 6.4 will by default uses TLSv1 and rejects cipher requests for SSLv2 and SSLv3. EAP is not currently expected to be vulnerable to this flaw.

Do I need to update my EAP 5.2 installation?

EAP can be configured to use the Java cryptography provider (JSSE) or the native provider (APR/OpenSSL). If you are using the Apr/OpenSSL provider then you should take the following steps:

• Red Hat Enterprise Linux

  • Upgrade OpenSSL for your version. (see the Resolve Tab of this article for RHSAs)

• Windows or Solaris

  • An update for the openssl libraries will be available on the Customer Service Platform. This update will replace the libssl and libeay libraries and openssl application.

EAP 5.2 is being tested on Windows to assess vulnerability to this to this flaw.

Do I need to update my EWS 2.1 installation?

This flaw only affects WIndows and Solaris installations where APR/OpenSSL has been configured as the security provider. EWS 2.1 currently support SSLv2 and SSLv3.

If you are using the Apr/OpenSSL provider then you should take the following steps:

• Red Hat Enterprise Linux

  • Upgrade OpenSSL for your version. (see the Resolve Tab of this article for RHSAs)

• Windows or Solaris

  • An update for the openssl libraries will be available on the Customer Service Platform. This update will replace the libssl and libeay libraries and openssl application.

A: Yes EWS 2.1 is affected, updates will be available from the Customer Service Portal. This flaw only affects WIndows and Solaris installations where APR/OpenSSL has been configured as the security provider. The default JSSE configuration is not affected. Updates will be available from the Customer Service Portal.

Do I need to update my EWS 3.0.2 installation?

This flaw only affects WIndows and Solaris installations where APR/OpenSSL has been configured as the security provider. EWS 3.0.2 currently support SSLv2 and SSLv3. EWS 3.0.3 when released will no longer offer SSLv2 or SSLv3.

If you are using the Apr/OpenSSL provider then you should take the following steps:

• Red Hat Enterprise Linux

  • Upgrade OpenSSL for your version. (see the Resolve Tab of this article for RHSAs)

• Windows or Solaris

  • An update for the openssl libraries will be available on the Customer Service Platform. This update will replace the libssl and libeay libraries and openssl application.

What is the status of the tomcat-native package?

The tomcat native package is not affected by this flaw. the tomcat-native package relies on the system supplied OpenSSL libraries.

Related Issues

Divide-and-conquer session key recovery in SSLv2 ( CVE-2016-0703 ) Severity: Moderate

It was discovered that the SSLv2 servers using OpenSSL accepted SSLv2 connection handshakes that indicated non-zero clear key length for non-export cipher suites. An attacker could use this flaw to decrypt recorded SSLv2 sessions with the server by using it as a decryption oracle.

Bleichenbacher oracle in SSLv2 ( CVE-2016-0704 ) Severity: Moderate

It was discovered that the SSLv2 protocol implementation in OpenSSL did not properly implement the Bleichenbacher protection for export cipher suites. An attacker could use a SSLv2 server using OpenSSL as a Bleichenbacher oracle.