OpenSSL是實現(xiàn)用于Web認(rèn)證的SSL / TLS協(xié)議的流行通用加密庫,最近遭受了幾個漏洞。例如CVE-2017-3731:截斷數(shù)據(jù)包可能導(dǎo)致OpenSSL中的拒絕服務(wù)和SSL死亡警報(CVE-2016-8610)可能導(dǎo)致OpenSSL服務(wù)器的拒絕服務(wù)。現(xiàn)在探討另一個高度嚴(yán)重的錯誤CVE-2017-3733,Encrypt-Then-MAC重新協(xié)商崩潰可能導(dǎo)致拒絕服務(wù)。
在SSL / TLS加密數(shù)據(jù)之前,它運行握手和ChangeCipherSpec協(xié)議。在握手階段,客戶端和服務(wù)器決定使用哪些加密算法。一旦協(xié)商完成,客戶端和服務(wù)器就會發(fā)送一個ChangedCipherSpec消息,之后通過協(xié)商的算法對流量進(jìn)行加密。
加密數(shù)據(jù)以SSL / TLS中的消息認(rèn)證碼(MAC)的兩種方式之一發(fā)送。
1. MAC-then-encrypt:該方法計算純文本的MAC,并將其與純文本進(jìn)行連接,并在其上運行加密算法。
2. Encrypt-then-MAC:密文通過加密明文生成,然后附加加密明文的MAC。
如果ClientHello消息不包含Encrypt-Then-Mac擴(kuò)展名,則默認(rèn)值為MAC-then-encryption模式,如果ClientHello具有Encrypt-Then-Mac擴(kuò)展名,服務(wù)器將在加密數(shù)據(jù)后計算MAC。
如果客戶端或服務(wù)器希望更改用于加密的算法,則可以重新協(xié)商他們已經(jīng)同意的Cipher_Suites。這可以通過發(fā)起新的握手在數(shù)據(jù)傳輸期間發(fā)生,這種情況發(fā)生在現(xiàn)有的SSL連接上
觸發(fā)漏洞
OpenSSL提供了這個解釋:
如果Encrypt-Then-Mac擴(kuò)展名在原始握手中不協(xié)調(diào)(或反之亦然),則在重新協(xié)商握手過程中,這可能導(dǎo)致OpenSSL崩潰(取決于密碼)。客戶端和服務(wù)器都受到影響。“
說客戶端使用默認(rèn)的MAC-then-encryption模式與服務(wù)器啟動TLS握手。如果客戶端稍后重新協(xié)商啟用了Encrypt-then-MAC擴(kuò)展,并在ChangeCipherSpec消息之前以該模式發(fā)送加密數(shù)據(jù),則服務(wù)器將崩潰,導(dǎo)致拒絕服務(wù)。
當(dāng)客戶端觸發(fā)此漏洞時,服務(wù)器會在ssl3_get_record函數(shù)的ssl3_record.c文件中崩潰:
崩潰發(fā)生在352行當(dāng)檢查mac_size是否小于EVP_MAX_MD_SIZE(64字節(jié))時:
在if函數(shù)中會檢查是否在服務(wù)器中設(shè)置了Encrypt-then-MAC標(biāo)志。if條件中的宏:
在重新協(xié)商時使用Encrypt-then-MAC擴(kuò)展名發(fā)送ClientHello數(shù)據(jù)包時,TLS1_FLAGS_ECRYPT_THEN_MAC標(biāo)志已被設(shè)置。所以控制將進(jìn)入if條件。但是由于ChangeCipherSpec消息尚未傳遞給服務(wù)器,因此不知道它必須使用Encrypt-then-MAC。
在行號上設(shè)一個斷點352和檢查mac_size變量顯示值0xffffffff,大于EVP_MAX_MD_SIZE(64)。因此if條件失敗,服務(wù)器崩潰。
我們來看看代碼,找到mac_size變量如何獲取值0xffffffff。EVP_MD_CTX_size函數(shù)計算mac_size。
當(dāng)消息摘要值為null時,返回-1。0xffffffff是-1的二進(jìn)制補碼。這意味著“s-> read_hash”返回null,因為服務(wù)器嘗試使用MAC-then-encrypt模式計算哈希。
提示所有管理員應(yīng)將OpenSSL更新為最新版本。
參考來源:https://securingtomorrow.mcafee.com/mcafee-labs/vulnerable-openssl-handshake-renegotiation-can-trigger-denial-service/,信息安全實驗室小編翻譯整理,轉(zhuǎn)載請注明來自CFCA信息安全實驗室