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
• Red Hat JBoss Enterprise Web Server 3.0
• Red Hat JBoss Enterprise Application Platform 6

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)?

Impact to systems

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. Server that does not enable SSLv2 can also be vulnerable if it does not enable SSLv2, but shares its private RSA key with another server. For example, 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 e.g. 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 non-RSA key exchange, such as Diffie-Hellman or Elliptic Curve Diffie-Hellman, can not be decrypted using the DROWN attack.

What configurations are vulnerable to this attack?

• TLS servers which support SSLv2 are vulnerable. Most daemons capable of communication over TLS in Red Hat Enterprise Linux are linked against the OpenSSL cryptographic library. OpenSSL removed support for SSLv2 cipher suites in openssl-1.0.0. Red Hat Enterprise Linux 6 and 7 ship openssl-1.0.1e and they contain this patch. However it was found that OpenSSL servers do not respect the cipher suites advertised in the ServerHello handshake message, which could result in export SSLv2 cipher suites being used even if they were explicitly disabled. Also, the SSLv2 protocol itself was enabled. The flaw was assigned CVE-2015-3197 and is being fixed by the security advisories listed in the Resolution section below.

• The NSS (Network Security Services) library available in Red Hat Enterprise Linux does not enable SSLv2 by default.

• Services which do not use SSLv2 , but share their RSA keys with those services which have SSLv2 support, are also vulnerable.

• This attack can only be conducted if RSA cipher suites for key exchange are enabled on the server. Other asymmetric protocols like DHKE and ECC are not vulnerable.

• Lastly, the attack can be conducted in real time for OpenSSL servers which are vulnerable to CVE-2015-0293 . This security flaw has been previously addressed by RHSA-2015:0800 for Red Hat Enterprise Linux 5, RHSA-2015:0715 for Red Hat Enterprise Linux 6 and RHSA-2015:0716 for Red Hat Enterprise Linux 7. This attack, which combines the SSLv2 protocol flaw and the OpenSSL implementation flaw, is dubbed as Special DROWN.

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.

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.