DROWN：利用 SSLv2 在 TLS 进行跨协议攻击（CVE-2016-0800)

Red Hat 产品安全团队发现 SSLv2 协议漏洞，并为其指定 [CVE-2016-0800]（https://access.redhat.com/security/cve/CVE-2016-0800），该漏洞可用于跨协议攻击，也称 DROWN - 即 “使用过时且安全性较低的方法解密 RSA” 的字母缩写（Decrypting RSA using Obsolete and Weakened eNcryption）。

概述

一组安全问题研究人员发现 SSLv2（安全套接字层协议版本 2）容易受到 Bleichenbacher RSA padding oracle 攻击，这种攻击可以在不了解匹配私有 RSA 密钥的情况下解密 RSA 密码文本。这可以通过观察拥有这个私钥的服务器的响应完成，并使用那个密钥执行攻击者提供的密码文本解密。研究人员还演示了一个新的跨协议攻击，这种攻击可以利用这个 SSLv2 弱点，解密使用较新的协议版本 SSLv3 或任意当前 TLS（传输层安全）版本（1.0-1.2）的 SSL/TLS 会话。这个漏洞是 SSLv2 协议问题，并会影响该协议的所有实施。研究人员将这个攻击成为“一般” DROWN。

另外还在 OpenSSL 加密法以及 SSL/TLS 存储库中部署的 SSLv2 协议中发现漏洞，这个漏洞便于完成更有效的 DROWN 变体攻击，也称 特殊 DROWN。为这些问题指定 CVE-2016-0703 和 CVE-2016-0704，且最近成为 CVE-2015-0293 修复的一部分。

有关这个攻击的详情，请查看研究人员论文，论文标题：“DROWN：使用 SSLv2 破解 TLS”，网址：https://drownattack.com/drown-attack-paper.pdf。

背景

SSLv2 协议存在安全隐患，并在 1996 年发布其替代产品 SSLv3 后被视为不安全的协议。并于 2011 年通过 RFC 6176 正式宣布弃用。目前其在互联网中的应用受到限制，因为现代的 SSL/TLS 客户端要么根本不支持这个协议版本，要么会尽可能使用较新的版本。但很多 SSL/TLS 服务器仍启用该协议。这样的设置可允许非常老旧的客户端与服务器连接，且在发现 DROWN 攻击前，也未发现支持较新协议版本客户端的连接有安全隐患。

受 DROWN 攻击影响的配置

服务器若在启用 SSLv3 或 TLSv1.x 外还启用了 SSLv2 协议，且使用 RSA 密钥交换密码套件，就容易受到 DROWN 攻击。即使服务器不启用 SSLv2 协议，但若与另一个服务器或使用 SSLv2 启用的服务共享器专用 RSA 密钥，则也容易受到 DROWN 攻击。例如：某个网页服务器虽然没有启用 SSLv2 协议，但如果与其他服务器，比如可能在同一主机中运行的启用了 SSLv2 协议的 IMAP
服务器共享其 RSA 密钥，则也可以使用 DROWN 方法对其进行攻击。有效执行此类攻击需要系统使用弱密码或导出 SSLv2 密码。

对于使用非 RSA 密钥交换的 SSL/TLS 连接，比如 Diffie-Hellman 或者椭圆曲线 Diffie-Hellman，则无法使用 DROWN 攻击解密。

攻击描述及影响

研究人员提供的 DROWN 描述包括以下步骤：

• 攻击者首先需要使用该西医的任意版本及 RSA 密码套件记录一定数量的客户端和服务器之间 SSL/TLS 会话。这些记录中的一个会话将会被解密。研究人员表示约 1000 个会话就足以完成攻击。

• 随后，攻击者会打开很多到该服务器的 SSLv2 连接。对于其中的一些连接，攻击者需要使用暴力破解 40 字节会话密钥（如果可以使用 SSLv2 EXPORT 密钥中的一个）或者暴力破解 56 字节会话密钥（用于使用 DES 的密钥套件）。研究人员预计需要月 4 万个连接。

• 随后攻击者就可以根据最初记录的握手信息之一解密“预主密钥”数据。那个数据是用来生成对称会话密钥，因此可解密整个记录的 SSL/TLS 会话。还可以从解密的会话中获得额外的敏感数据，比如认证凭据或 cookies。

研究人员表示他们可以通过 1000 个记录的握手信息、40000 个 SSLv2 连接及 2⁵⁰ 次离线计算，在使用 2048 字节 RSA 密钥的服务器中解密 TLS 1.2 握手信息。若使用共有云资源，则可在 8 小时以内完成攻击，成本仅 440 美元。

他们还指出使用特殊 DROWN 攻击可将所需 SSLv2 连接数降低至 14000 个，并可使用单一工作站在 3 分钟内完成。这样就有可能利用这个漏洞执行活跃的中间人（MITM）攻击，并模拟 TLS 服务器连接到 TLS 客户端。

支持 SSLv2 的 SSL 和 GLS 存储库

Red Hat 产品包括可以部署 SSLv2 支持的以下组件。可使用这些 SSL/TLS 存储库根据应用程序使用方式启用该功能。

OpenSSL 中的 SSLv2

使用 OpenSSL 的应用程序必须选择连接方法以便通知该存储库它们要使用的 SSL/TLS 协议版本。OpenSSL 连接方法要么是启用单一协议版本，要么是使用特殊方法 SSLv23启用该存储库支持的所有协议版本。这是最常用的连接方法。选择这个方法时会自动启用 SSLv2 协议。应用程序必须在相关 SSL_CTX or SSL对象中明确设置 SSL_OP_NO_SSLv2选项，以便禁用 SSLv2。虽然很多应用程序均要进行此操作，可以是无条件的，也可以是根据其配置，但也有些程序使用默认的启用协议集合。因此使用 OpenSSL 存储库的应用程序一般会在启用 SSLv2 的情况下运行。

Red Hat 产品包括在 OpenSSL 中应用的以下变更以解决这个问题：

• 使用 SSLv23连接方法时默认不再启用 SSLv2 协议。
• 现在禁用了所有使用 40 字节（EXPORT）或者 56 字节（单一 DES）对称加密密钥的SSLv2 加密套件，且不再能够使用它们。不再提供以下加密套件：
  • 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
• 用于 Red Hat Enterprise Linux 4 和 5 的所有更新中的 openssl软件包 OpensSSL 版本现在均检查 OPENSSL_ENABLE_SSL2 环境变量。如果定义了该变量，则会在使用 SSLv23 连接方法时默认启用 SSLv2。需要时可使用这个环境变量重新启用 SSLv2。

更改 SSLv23 连接方法不会影响 SSLv2 连接方法，并仍可用来建立使用 SSLv2 协议的连接。

还请注意，虽然 Red Hat Enterprise Linux 6 和 7 中包含的 OpenSSL 版本中的 DEFAULT 密码列表不包括任何 SSLv2 密码套件，但这个默认设置不会妨碍服务器从强制使用禁用的密码套件的客户端接受 SSLv2 连接。已为这个问题指定 CVE-2015-3197，并将在解决 DROWN 问题的更新中修复。

网络安全服务（Network Security Services）中的 SSLv2

NSS 加密法存储库实施 SSLv2 协议，但不会默认启用该协议。应用程序需要明确要求该存储库启用 SSLv2 后方可使用。Red Hat Enterprise Linux 7 中附带的 NSS 版本根本不允许启用 SSLv2 协议。使用 NSS 存储库的应用程序一般不会在启用 SSLv2 的情况下运行。

因为 NSS 存储库默认不启用 SSLv2，因此没有计划要立即解决这个 DROWN 问题。预期在 Red Hat Enterprise Linux 6 今后的更新中会采用与 Red Hat Enterprise Linux 7 类似的方法禁用该协议。

不支持 SSLv2 的 SSL 和 TLS 存储库

Red Hat 产品包括以下一些实施 TLS 或 SSL 协议版本，但不支持 SSLv2 的组件。因此，这些组件不会受这个问题影响。注：使用这些受影响存储库的应用程序如果与其他使用支持 SSLv2 协议的 SSL/TLS 存储库共享其私有 RSA 密钥，则可能仍会受到 DROWN 攻击的影响。

• GnuTLS
• OpenJDK（软件包 java-1.6.0-openjdk、java-1.7.0-openjdk、java-1.8.0-openjdk）
• Oracle JDK（软件包java-1.6.0-sun、java-1.7.0-oracle、java-1.8.0-oracle）
• IBM JDK（软件包 java-1.6.0-ibm、java-1.7.0-ibm、java-1.7.1-ibm、java-1.8.0-ibm）

解决方案

Red Hat 建议客户对其受影响的系统进行风险优先级分析，并立即应用可用补丁修复这个问题。更新后重启系统是保证所有受影响服务使用已更新 OpenSSL 库的最安全方法。如果无法长期，则要求在应用该补丁后重启所有依赖 OpenSSL 的网络服务。

特此鸣谢

Red Hat 愿籍此机会感谢 OpenSSL 项目组报告这个问题，特别是具体发现这个问题的 Nimrod Aviram 和 Sebastian Schinzel。

常见问题

如何在应用程序 X 中禁用 SSLv2？

有关如何在不同 Red Hat Enterprise Linux 版本的不同应用程序中更改与 SSL/TLS 有关的设置的详情，比如启用的协议版本，请参考知识库文章 [如何在 RHEL 'Y' 中保护 'X'？]。

鉴于这个问题，是否需要重新生成服务器密钥或证书？

不需要。DROWN 不会直接暴露您的 RSA 私钥，而是会将目标锁定在 SSL/TLS 连接握手机制中生成，并用来进行对称加密的各个会话密钥。破解那些密钥就可以解密具体 SSL/TLS 会话。因此，即使探测到容易受到 DROWN 攻击的服务，也没有必要重新生成服务密钥或证实。

** 在 Red Hat 产品中附带的 Apache httpd web 服务器版本是否启用了 SSLv2？**

Apache httpd web 服务器可使用于以下模块之一提供 HTTPS 服务：

• mod_ssl - 这个模块使用 OpenSSL 加密存储库，并包含在 Apache httpd web 服务器发行本中。
• mod_nss - 这个模块使用 NSS 加密存储库，且由 Apache httpd 项目以外的人员开发并发布。

Red Hat 产品中包含这两个模块。

使用 mod_ssl 进行的默认 httpd 设置为：

• Red Hat Enterprise Linux 7 包含的 httpd 版本位于 Red Hat Software Collections 以及 Red Hat JBoss Web Server 3 中的 httpd24 集合，它是基于 upstream httpd 版本 2.4，无法将其配置为启用 SSLv2。

• Red Hat Enterprise Linux 5 和 6、Red Hat JBoss Web Server 1 和 2 以及 Red Hat JBoss Enterprise Application Platform 6 中的 httpd 版本是基于 upstream httpd versions 2.2。可将那些版本配置为使用 SSLv2，但在默认配置中禁用了那个协议。/etc/httpd/conf.d/ssl.conf 配置文件包括禁用 SSLv2 的配置指令：

SSLProtocol all -SSLv2

• Red Hat Enterprise Linux 4 中附带的 httpd 版本是基于 upstream httpd 版本 2.0。默认配置启用 SSLv2，并可通过在 /etc/httpd/conf.d/ssl.conf 配置文件中添加以上列出的相同 SSLProtocol 指令，并重启 httpd 服务禁用 SSLv2。

使用 mod_nss 进行的默认 httpd 设置为：

• Red Hat Enterprise Linux 5、6 和 7 中附带的 mod_nss 版本不会默认启用 SSLv2。/etc/httpd/conf.d/nss.conf 配置文件包括以下配置指令，根据所使用的 mod_nss 软件包版本，只能启用 SSLv3 或者后的版本，或者 TLSv1.0 或之后的版本：

NSSProtocol SSLv3、TLSv1
NSSProtocol TLSv1.0、TLSv1.1、TLSv1.2

注： 因为已了解到 SSLv3 协议问题，我们还是建议禁用该版本。有关详情及如何在 Red Hat 产品的不同组件中禁用 SSLv3 协议的步骤，请参考相关 POODLE: SSLv3 vulnerability (CVE-2014-3566) 文章。

Red Hat Enterprise Linux 附带的邮件 SMTP 服务器是否启用了 SSLv2？

Red Hat Enterprise Linux 5、6 和 7 中的 Postfix 及 Sendmail 邮件服务器默认配置均不启用 SSL/TLS 加密。

如果系统管理员在 Postfix 中启用 SSL/TLS，则默认会使用随机加密法启用 SSLv2，并使用强制加密法禁用。在 Red Hat Enterprise Linux 6 和 7 中，可使用 smtpd_tls_protocols 配置选项禁用使用随机加密启用的 SSLv2。

如果系统管理员在 Sendmail 中启用 SSL/TLS，则默认会启用 SSLv2。在 Red Hat Enterprise Linux 5、6 和 7 中，可使用 ServerSSLOptions 配置选项禁用 SSLv2。

有关如何在 Postfix 和 Sendmail 中配置 SSL/TLS 的链接详情请查看问题"如何在应用程序 X 中禁用 SSLv2？"。

是否需要更新 EAP 6.4 安装？
可将 EAP 配置为使用 Java 加密提供者（JSSE）或其他内置提供者（APR/OpenSSL）。如果要使用 APR/OpenSSL 提供者，则应执行以下操作：

• Red Hat Enterprise Linux
  将 OpenSSL 升级至您的版本。
• Windows 或者 Solaris
  将在客户服务平台中为您提供 openssl 库更新。这个更新将替换 libssl 和 libeay 库以及 openssl 应用程序。

已在 Windows 系统中使用 APR/OpenSSL 测试了 EAP 6.4，虽然技术上讲 OpenSSL 库需要更新，但 EAP 6.4 会默认使用 TLSv1，并拒绝 SSLv2 和 SSLv3 的加密要求。EAP 目前应不会受到此漏洞的影响。

是否需要更新 EAP 5.2 安装？
可将 EAP 配置为使用 Java 加密提供者（JSSE）或其他内置提供者（APR/OpenSSL）。如果要使用 APR/OpenSSL 提供者，则应执行以下操作：

• Red Hat Enterprise Linux
  将 OpenSSL 升级至您的版本。
• Windows 或者 Solaris
  将在客户服务平台中为您提供 openssl 库。这个更新将替换 libssl 和 libeay 库以及 openssl 应用程序。

已在 Windows 中对 EAP 5.2 就这个漏洞的影响进行了测试。

是否需要更新 EWS 2.1 安装？
这个漏洞会影响已使用 APR/OpenSSL 作为安全提供者的 Windows 和 Solaris 安装。EWS 2.1 目前支持 SSLv2 和 SSLv3。
如果您使用的是 APR/OpenSSL 提供者，则应执行以下操作：

• Red Hat Enterprise Linux
  将 OpenSSL 升级至您的版本。
• Windows 或者 Solaris
  将在客户服务平台中为您提供 openssl 库。这个更新将替换 libssl 和 libeay 库以及 openssl 应用程序。

A：是，EWS 2.1 受到影响，将会在客户服务平台中提供更新。这个漏洞只会影响已使用 APR/OpenSSL 作为安全提供者的 Windows 和 Solaris 安装。默认 JSSE 配置不会受影响。将在客户服务平台中提供更新。

是否需要更新 EWS 3.0.2 安装？
这个漏洞只会影响已使用 APR/OpenSSL 作为安全提供者的 Windows 和 Solaris 安装。EWS 3.0.2 目前支持 SSLv2 和 SSLv3。以后发布的 EWS 3.0.3 将不再提供 SSLv2 和 SSLv3。

如果您使用的是 APR/OpenSSL 提供者，则应执行以下操作：

• Red Hat Enterprise Linux
  将 OpenSSL 升级至您的版本。
• Windows 或者 Solaris
  将在客户服务平台中为您提供 openssl 库。这个更新将替换 libssl 和 libeay 库以及 openssl 应用程序。

tomca 内置软件包会受到怎样的影响？

Tomcat 内置软件包不会受这个漏洞的影响。tomcat 内置软件包依赖该系统提供的 OpenSSL 库。