昨天，2022 年 11 月 1 日，OpenSSL 發佈了 3.0.7 版，以修補 CVE-2022-3602 和 CVE-2022-3786，這是 OpenSSL 3.0.x 加密庫中的兩個 HIGH 級別風險漏洞。Cloudflare 不受這些漏洞的影響，因為我們在產品中使用了 BoringSSL。
這些漏洞是記憶體損壞問題，攻擊者可能能夠在受害者的電腦上執行任意代碼。CVE-2022-3602 最初被宣佈為 CRITICAL 嚴重性漏洞，但由於該漏洞被認為難以透過遠端程式碼執行 (RCE) 進行利用，因此已降級為 HIGH。與以前 OpenSSL 使用者幾乎普遍易受攻擊的情況不同，使用其他版本 OpenSSL（如 1.1.1）的軟體不容易受到此攻擊。
這些問題會對用戶端和伺服器產生怎樣的影響？
這些漏洞存在於負責 X.509 憑證驗證的程式碼中——通常在用戶端執行，以驗證伺服器和所提供的憑證。當受害者（用戶端或伺服器）滿足以下幾個條件時，會受到此漏洞的影響：
- 惡意憑證需要由受害者信任的憑證頒發機構簽名。
- 受害者需要驗證惡意憑證或忽略來自瀏覽器的一系列警告。
- 受害者需要執行低於 3.0.7 的 OpenSSL 3.0.x 版本。
要使用戶端受到此漏洞的影響，他們必須造訪提供包含漏洞利用有效負載的憑證的惡意網站。此外，此惡意憑證必須由受信任的憑證頒發機構 (CA) 簽名。
如果具有易受攻擊的 OpenSSL 版本的伺服器支援相互驗證——在這種情況下，用戶端和伺服器都提供有效且已簽名的 X.509 憑證，且用戶端能夠向伺服器提供具有漏洞利用有效負載的憑證。
您應該如何處理此問題？
如果您正在管理執行 OpenSSL 的服務：您應該修補易受攻擊的 OpenSSL 封裝。在 Linux 系統上，您可以確定是否有任何處理序使用 lsof 命令動態載入 OpenSSL。下面是一個查找 NGINX 使用的 OpenSSL 的範例。
root@55f64f421576:/# lsof | grep libssl.so.3
nginx 1294 root mem REG 254,1 925009 /usr/lib/x86_64-linux-gnu/libssl.so.3 (path dev=0,142)
一旦您的 Linux 發行版的封裝維護者發佈了 OpenSSL 3.0.7，您就可以透過更新封裝來源和升級 libssl3 封裝來進行修補。在 Debian 和 Ubuntu 上，這可以透過 apt-get upgrade 命令來完成。
root@55f64f421576:/# apt-get --only-upgrade install libssl3
話雖如此，但您可能正在執行 lsof 命令無法找到的易受攻擊的 OpenSSL 版本，因為您的處理序是靜態編譯的。務必要更新您負責維護的靜態編譯軟體，並確保在未來幾天內更新您的作業系統和其他可能包含易受攻擊的 OpenSSL 版本的已安裝軟體，這一點非常重要。
重點
藉助 Cloudflare 使用的 BoringSSL，我們確信該問題不會在漏洞發布日期之前影響我們。
從更廣泛的意義來說，該漏洞提醒人們記憶體安全仍然是一個重要問題。此問題可能難以利用，因為它需要一個惡意製作的憑證並由受信任的 CA 簽名，並且憑證頒發者可能會開始驗證他們簽名的憑證是否不包含利用這些漏洞的有效負載。但是，鑒於問題的嚴重性，修補軟體並將易受攻擊的 OpenSSL 封裝升級到 OpenSSL 3.0.7 仍然很重要。