Warning message

This translation is outdated. For the most up-to-date information, please refer to the English version.

DROWN:使用 SSLv2,在 TLS 上的跨通訊協定攻擊(CVE-2016-0800)

Red Hat 產品安全部已得知 SSLv2 通訊協定的弱點,且指定為 CVE-2016-0800,這跨通訊協定的攻擊又稱為 DROWN(使用過時且孱弱的加密法,來解密 RSA——Decrypting RSA using Obsolete and Weakened eNcryption)。

總覽

安全研究人員發現,SSLv2 無法抵抗 Bleichenbacher RSA padding oracle attack(一種在封包中填入額外資訊的攻擊方法),這可以在沒有相對應的私密 RSA 金鑰情況下,用來解密 RSA 的加密文字。這可以透過觀察伺服器(有私密金鑰)的回應,然後使用金鑰進行攻擊者提供的加密文字。研究人員也展示了新的跨通訊協定攻擊,能使用較新的通訊協定版本(SSLv3 或任何現有 TLS(1.0 - 1.2)版本),讓 SSL/TLS session 使用這個 SSLv2 的弱點。這弱點是 SSLv2 的問題,會影響所有使用此通訊協定的程式。研究人員將此攻擊稱為「一般性」的 DROWN。

除此之外,OpenSSL 加密法與 SSL/TLS 函示庫中 SSLv2 通訊協定的實作都可找到這弱點,這能讓各種變體的 DROWN 攻擊更有效率,這類攻擊稱為「特別的」DROWN。這些問題已被指定為 CVE-2016-0703CVE-2016-0704,同時已經納入 CVE-2015-0293 修正檔。

關於此攻擊的進一步資訊,可以在研究人員名為〈DROWN: Breaking TLS using SSLv2〉(DROWN:使用 SSLv2 破解 TLS)的論文(https://drownattack.com/drown-attack-paper.pdf)中找到。

背景

SSLv2 通訊協定有已知的安全性問題,且在 1996 年 SSLv3 出現後,就被視為不安全的版本。2011 年 SSLv2 就已經透過 RFC 6176 淘汰。現在在網路上使用 SSLv2 的很少,因為更先進的 SSL/TLS 用戶端如果不是不再支援此通訊協定版本,就是會盡可能的使用新版本。然而,許多 SSL/TLS 伺服器依然啟用此版本。這類設定能讓非常舊的用戶端連上,在 DROWN 攻擊出版前,沒有任何來自支援較新版本的用戶端的連線暴露在安全問題中。

受 DROWN 攻擊影響的配置

如果伺服器在啟用了 SSLv3 或 TLSv1.x 以外、且使用了 RSA 金鑰來交換加密組合,也啟用了 SSLv2,就會可能暴露在 DROWN 攻擊下。如果伺服器未啟用 SSLv2,但與另一台啟用了 SSLv2 的伺服器或服務共享 RSA 金鑰,那麼也會有危險。舉例來說,如果一台未啟用 SSLv2 的網站伺服器與一台啟用了 SSLv2 的 IMAP 伺服器(可能位於同一台主機上、且這主機並未啟用 SSLv2)共享了 RSA 金鑰,那麼 DROWN 攻擊也可以用來解碼這台網站伺服器之 HTTPS session。要有效的進攻,就需要使用這弱點或匯出 SSLv2 的加密程式。

使用非 RSA 金鑰交換機制(例如 Diffie-Hellman 或 Elliptic Curve Diffie-Hellman)的 SSL/TLS 連線,就無法透過 DROWN 攻擊進行解碼。

攻擊的描述與衝擊

研究人員所描述的 DROWN 攻擊包含了以下步驟:

  • 首先,攻擊者需要使用任何版本的通訊協定、RSA 加密組,記錄用戶端與伺服器端的多個 SSL/TLS session。其中一項紀錄會被解密。研究人員指出大約 1,000 筆 session 記錄就足夠進行攻擊。

  • 接下來,攻擊者會開啟任何 SSLv2 連線,連至伺服器。針對有些連線,攻擊者需要暴力攻擊 40 位元(如果可以使用其中一個 SSLv2 EXPORT 加密)或 56 位元(使用 DES 的加密組)的 session 金鑰。研究人員預計這大概需要 40,000 次連線。

  • 之後,攻擊者就可以從原始記錄的 handshake 中解密「premaster secret」資料。該資料會用來產生 session 的對稱金鑰,然後解密整個已記錄的 SSL/TLS session。從整個解密 session 就可以取得額外的機密性資訊,例如身分認證資料或 cookies。

研究人員表示,他們可以在使用了 2048 位元的 RSA 金鑰的伺服器上,透過 1,000 筆已記錄的 handshake、40,000 個 SSLv2 連線、以及 250 次的離線運算,解密 TLS 1.2 的 handshake。這次攻擊在成本低於美金 $440 的公眾雲端服務上進行,花不到八小時的時間。

他們也指出,使用「特別的」DROWN 攻擊能在單一工作站上,降低 SSLv2 的連線次數至 14,000 次,花不到三分鐘。因此,使用此漏洞來進行 MITM(man-in-the-middle)攻擊,假扮 TLS 伺服器來連接 TLS 用戶端。

支援 SSLv2 的 SSL 與 TLS 函示庫

Red Hat 包括以下使用了 SSLv2 通訊協定的元件。根據應用程式使用 SSL/TLS 函示庫的情形,系統可能開啟了對這通訊協定的支援。

OpenSSL 中的 SSLv2

使用 OpenSSL 的應用程式必須選擇連線方法,以決定要使用的 SSL/TLS 通訊協定版本。OpenSSL 連線方法要不是啟用了單一通訊協定版本,就是特別的方法「SSLv23」能用來啟用函示庫所支援的所有通訊協定版本。這是最常用的連線方法。選擇這方法時,SSLv2 通訊協定被會自動啟用。應用程式必須在相關的「SSL_CTX」或「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」套件更新版之 OpenSSL 版本現在會檢查「OPENSSL_ENABLE_SSL2」環境變數;如果這變數已定義,使用「SSLv23」連線方法時,會預設啟用 SSLv2。需要的話,這環境變數可以用來重新啟用 SSLv2。

「SSLv2」連線方法不會透過改變「SSLv23」連線方法而受到影響,依舊可以透過使用 SSLv2 通訊協定來建立連線。

也請注意,Red Hat Enterprise Linux 6 與 7 的 OpenSSL 版本中的「DEFAULT」加密清單會排除所有 SSLv2 加密組,這預設值不會避免來自強制使用已停用加密組的用戶端,使用 SSLv2 連上伺服器。這問題已經指定為 CVE-2015-3197,同時也在解決 DROWN 問題的更新檔中獲得解決。

NSS 中的 SSLv2

NSS(網路安全服務,Network Security Service)加密函式庫實作了 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。因此,這些元件並未受此次問題的影響。請注意,如果這些未受影響的函式庫的應用程式與另一個應用程式共享了 RSA 私密金鑰,而這應用程式又使用了支援 SSLv2 的 SSL/TLS 函式庫,那還是可能受到 DROWN 攻擊的影響。

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

解決方法

Red Hat 建議使用者在受影響的系統上進行風險優先順序分析,並立即套用可用的更新檔,以解決問題。升級後重新開機是最安全的方式,確定所有受影響的服務都使用了更新後的 OpenSSL 函式庫。如果系統不能重新開機,那就需要在套用更新檔之後,重新啟動所有依賴 OpenSSL 的網路服務。

產品 套件 建議
Red Hat Enterprise Linux 4 延伸生命週期的支援項目 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 長壽版 openssl-0.9.8e-12.el5_6.13 RHSA-2016:0304
Red Hat Enterprise Linux 5.9 長壽版 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 進階升級支援 openssl-1.0.0-20.el6_2.8 RHSA-2016:0303
Red Hat Enterprise Linux 6.4 進階升級支援 openssl-1.0.0-27.el6_4.5 RHSA-2016:0303
Red Hat Enterprise Linux 6.5 進階升級支援 openssl-1.0.1e-16.el6_5.16 RHSA-2016:0303
Red Hat Enterprise Linux 6.6 延伸升級支援 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 延伸升級支援 openssl-1.0.1e-42.el7_1.10, openssl-1.0.1e-42.ael7b_1.10 RHSA-2016:0305
Red Hat JBoss Web Server 2.1 openssl 套用作業系統更新檔
Red Hat JBoss Web Server 3.0.1 openssl 套用作業系統更新檔
Red Hat JBoss Enterprise Application Platform 5.2 openssl 套用作業系統更新檔,Windows 與 Solaris 的更新檔製作中
Red Hat JBoss Enterprise Application Platform 6.4 openssl 套用作業系統更新檔,Windows 與 Solaris 的更新檔製作中

鳴謝

Red Hat 感謝 OpenSSL 專案小組回報這些問題。上游專案感謝最初的回報人員 Nimrod Aviram 與 Sebastian Schinzel。

常見問題集

如何停用應用程式 X 的 SSLv2?

請參閱知識庫文章如何防護 RHEL 'Y' 裡的應用程式 'X'? 得知如何改變 SSL/TLS 相關的設定,例如多種 Red Hat Enterprise Linux 版本的多應用程式中,啟用的通訊協定版本。

需不需要重新產生伺服器金鑰或憑證?

不會。DROWN 並不會直接暴露您的 RSA 私密金鑰;但會瞄準個別的 session 金鑰,這些金鑰會在SSL/TLS handshake 期間產生,用在對稱加密上。破解這些金鑰可以解密相對應的 SSL/TLS session。因此,即使一項服務被偵測到有 DROWN 漏洞,也沒有必要重新產生服務金鑰或憑證。

Red Hat 產品包含的 Apache httpd 網站服務是否啟用了 SSLv2?

Apache httpd 網站伺服器可以使用以下模組之一,來提供 HTTPS 服務:

  • mod_ssl - 這模組使用了 OpenSSL 加密函式庫,是 Apache httpd 網站服務的一部份。
  • mod_nss - 這模組使用了 NSS 加密函式庫,並非由 Apache httpd 專案所開發、散佈。

兩項模組都包括在 Red Hat 產品中。

使用 mod_ssl 的 httpd 之預設設定為:

  • Red Hat Enterprise Linux 7 所包含的 httpd 版本,位於Red Hat 軟體集、以及 Red Hat JBoss Web Server 3 的「httpd24」中,根基於上游的 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 版本都根基於上游的 httpd 2.2。這些版本可以配置為使用 SSLv2,然而,在預設配置上,這通訊協定是停用的。/etc/httpd/conf.d/ssl.conf 配置檔案包括以下配置指示,停用了 SSLv2:

SSLProtocol all -SSLv2
  • Red Hat Enterprise Linux 4 的 httpd 版本根基於上游的 http 2.0 版。預設配置啟用了 SSLv2,可以透過以下方式停用:在 /etc/httpd/conf.d/ssl.conf 同樣加入上述指示,,然後重新啟動 httpd 服務。

使用 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 產品中的多個元件,請見相關的 POODLE:SSLv3 弱點(CVE-2014-3566)一文。

Red Hat Enterprise Linux 的 SMTP 服務是否啟用了 SSLv2?

Red Hat Enterprise Linux 5、6 與 7 的 Postfix 與 Sendmail 郵件伺服器之預設設定並不會啟用 SSL/TLS 加密。

如果系統管理員在 Postfix 中啟用了 SSL/TLS 時,預設上會使用 opportunistic 加密啟用 SSLv2,並停用強制(mandatory)加密。在 Red Hat Enterprise Linux 6 與 7 中,可以透過 smtpd_tls_protocols 配置選項停用搭配 opportunistic 加密的 SSLv2。

如果系統管理員啟用了 Sendmail 中的 SSL/TLS,預設上會啟用 SSLv2。在 Red Hat Enterprise Linux 6 與 7 中,可以使用 ServerSSLOptions 配置選項來停用 SSLv2。

欲知如何配置 Postfix 與 Sendmail 中的 SSL/TLS,請參閱上述「如何停用應用程式 X 的 SSLv2?」連結。

我需要更新 EAP 6.4 嗎?
EAP 可以配置為使用 JSSE(Java 加密供應者,Java cryptography provider)或原生的供應者(APR/OpenSSL)。如果您使用了 Apr/OpenSSL 供應者,那麼請進行下列步驟:

  • Red Hat Enterprise Linux
    更新系統上的 OpenSSL。
  • Windows 或 Solaris
    客戶服務平台(Customer Service Platform)上將會有 openssl 函式庫的更新版。這項更新會取代 libssl 與 libeay 函式庫、openssl 應用程式。

EAP 6.4 已經在 Windows 使用 APR/OpenSSL 測試過,雖然技術上,OpenSSL 函式庫需要更新,但 EAP 6.4 預設上會使用 TLSv1,並拒絕 SSLv2 與 SSLv3 的加密請求。目前 EAP 並不會因為此弱點而受到影響。

我需要更新 EAP 5.2 嗎?
EAP 可以配置為使用 JSSE(Java 加密供應者,Java cryptography provider)或原生的供應者(APR/OpenSSL)。如果您使用了 Apr/OpenSSL 供應者,那麼請進行下列步驟:

  • Red Hat Enterprise Linux
    更新系統上的 OpenSSL。
  • Windows 或 Solaris
    客戶服務平台(Customer Service Platform)上將會有 openssl 函式庫的更新版。這項更新會取代 libssl 與 libeay 函式庫、openssl 應用程式。

目前正在 Windows 上測試 EAP 5.2 是否會受到這弱點的影響。

我需要更新 EWS 2.1 嗎?
這弱點只會影響 Windows 與 Solaris,其中 ARP/OpenSSL 已經配置為安全性供應者。目前 EWS 2.1 支援 SSLv2 與 SSLv3。
如果您使用了 Apr/OpenSSL 供應者,那麼請採取以下步驟:

  • Red Hat Enterprise Linux
    更新系統上的 OpenSSL。
  • Windows 或 Solaris
    客戶服務平台(Customer Service Platform)上將會有 openssl 函式庫的更新版。這項更新會取代 libssl 與 libeay 函式庫、openssl 應用程式。

答:需要。EWS 2.1 受到了影響,客戶服務平台(Customer Service Platform)上將會有更新版。這弱點只會影響 Windows 與 Solaris,其中 ARP/OpenSSL 已經配置為安全性供應者。預設的 JSSE 並未受到影響。更新檔案可以在客戶服務入口網站上找到。

我需要更新 EWS 3.0.2 嗎?
這弱點只會影響 Windows 與 Solaris,其中 ARP/OpenSSL 已經配置為安全性供應者。目前 EWS 3.0.2 支援 SSLv2 與 SSLv3。EWS 3.0.3 釋出時不再提供 SSLv2 或 SSLv3。

如果您使用了 Apr/OpenSSL 供應者,那麼請採取以下步驟:

  • Red Hat Enterprise Linux
    更新系統上的 OpenSSL。
  • Windows 或 Solaris
    客戶服務平台(Customer Service Platform)上將會有 openssl 函式庫的更新版。這項更新會取代 libssl 與 libeay 函式庫、openssl 應用程式。

tomcat-native 套件的狀態為何?

tomcat 原生套件並不會受到此漏洞的影響。tomcat-native 套件依靠系統提供 OpenSSL 函式庫。