UEFI固件使用OpenSSL暴露了軟件材料清單（SBOM）的弱點，戴爾、惠普和聯想中招 - 網安

Binarly REsearch團隊近日深入研究了最近的OpenSSL安全更新給UEFI固件供應鏈生態系統帶來怎樣的影響以及OpenSSL版本在固件環境中是如何廣泛使用的。研究結果不容樂觀。

科技行業正在積極討論使用“軟件材料清單”（SBOM）來化解供應鏈安全風險。為了確保供應鏈安全實踐落地，必須加強軟件依賴項方面的透明度。以前，任何一款軟件作為黑盒子來發布，并不提供與軟件依賴項和第三方組件相關的任何信息。固件在很大程度上也是如此。Binarly團隊在之前的一篇博文中討論了UEFI固件生態系統的多重復雜性和供應鏈分類，有興趣的讀者可以參閱：https://binarly.io/posts/The_Firmware_Supply_Chain_Security_is_broken_Can_we_fix_it。

SBOM是否有助于加強專有固件軟件包的透明度？答案很復雜。SBOM有助于人們更好地了解依賴項，但在許多情況下，諸廠商將SBOM信息與固件軟件包或映像文件分開來分發。當SBOM不相關或可能含有誤導性信息時，這就產生了與之前關于供應鏈問題的討論相同的問題。現在我們的供應鏈與SBOM密切相關，在許多情況下，SBOM是廠商提供的信息的靜態快照。

當固件不含有相應的源代碼時，如果沒有全面的代碼分析基礎設施，很難基于編譯后的二進制模塊來驗證SBOM信息。

本月早些時候，CISA發布了一份與OpenSSL最近的高危安全問題（CVE-2022-3602和CVE-2022-3786）相關的安全公告。CVE-2022-3602和CVE-2022-3786這兩個安全漏洞都與x.509證書驗證失敗有關，證書驗證失敗可能導致基于堆棧的緩沖區溢出。事實上，較舊的版本不受影響，比如OpenSSL 1.0.2和1.1.1。早期版本也不受影響，因為易受攻擊的代碼是在OpenSSL 3.0.0中首次引入的。

Binarly REsearch團隊決定深入研究這種緊急更新給UEFI固件供應鏈生態系統帶來了怎樣的影響以及OpenSSL版本在固件環境中是如何廣泛使用的。

深入核心

核心框架之一EDKII作為任何UEFI固件的一部分來使用，它在CryptoPkg組件中有自己的子模塊和OpenSSL包裝器庫（OpensslLib）。Github上的主要EDKII存儲庫經常更新，開發者社區經常關注安全問題。但其中一個主要問題是，這些更新給終端設備的供應鏈又帶來了怎樣的影響。

在許多情況下，固件是供應鏈所有層和終端客戶設備之間的單一故障點。

我們以前強調過，即使在設備廠商知道漏洞之后，在端點設備上部署這些補丁時，仍會一再出現失敗。但是說到第三方相關的代碼，就會帶來圍繞補丁部署的更復雜問題。

微軟最近在《2022年數字防御報告》中強調：分析的固件映像中32%含有至少10個已知的嚴重漏洞。

圖1

我們在自己的遙測數據中也看到了這一趨勢，證實這股勢頭在上升。據Binarly Platform在調查企業級廠商后得到的數據顯示，大約20%的固件更新含有至少兩到三個已知的漏洞（以前披露過）。

與利用新的漏洞（0-day）相比，部署使用1/N-day漏洞的固件攻擊的成本大幅降低。

不妨進一步了解聯想Thinkpad企業設備，以及在一個固件映像中使用了多少個不同版本的OpenSSL。

我們可以看到，同一個固件二進制包中至少使用了三個不同版本的OpenSSL：1.0.0a（2014）、1.0.2j（2018）和0.9.8zb（2014）。最新的OpenSSL版本是在2018年發布的，因此已過時四年。

許多與安全相關的固件模塊含有明顯過時的OpenSSL版本。其中一些模塊（比如InfineonTpmUpdateDxe）含有已知過時至少八年的易受攻擊的代碼。InfineonTpmUpdateDxe模塊負責更新英飛凌芯片上可信任平臺模塊（TPM）的固件。這清楚地表明了第三方依賴項存在的供應鏈問題，這些依賴項看起來從未收到更新，哪怕針對嚴重的安全問題。

在聯想企業設備上使用的OpenSSL的最新版本可以追溯到2021年夏天。下圖顯示了Binarly Platform檢測到的所有OpenSSL版本（用于最新的固件更新）和Linux供應商固件服務（LVFS）公共數據內容：

圖2

這些表清楚地反映了總體情況和同一設備固件代碼中使用不同OpenSSL版本的多樣化程度。為了更好地了解OpenSSL數據，不妨看看不同版本與各大企業廠商的設備上的發布日期有怎樣的聯系。

我們從Binarly OpenSSL的研究數據中可以看出，固件常常使用多個版本的OpenSSL。其背后的原因是，第三方代碼的供應鏈依賴它們各自的代碼庫，而設備固件開發人員常常無法獲得這些代碼庫。這就增加了供應鏈的復雜性。大多數OpenSSL依賴項作為庫靜態鏈接到特定的固件模塊，這些模塊創建編譯時依賴項，如果沒有深入分析代碼的功能，就很難識別這些依賴項。在過去，第三方代碼依賴項的問題不是在編譯代碼層面就能輕松解決的問題。

行業目前采取的做法是為單獨的模塊生成散列，與特定的版本版本號相關聯，以便連接SBOM層面的依賴項列表。這種做法適用于開源項目（比如用于驗證的Sigstore項目），但面對閉源生態系統，它總是以失敗告終。雖然散列提供了完整性信息，但無法為閉源項目保證SBOM內容和完整性。從這個意義上說，涉及到在二進制層面進行驗證的編譯代碼時，我們迫切需要一個額外的SBOM驗證層，即與廠商提供的實際SBOM相匹配的第三方依賴項信息列表。

完整性提供不了代碼級別的可見性，根據二進制模塊的散列確定依賴項的范圍很困難。當依賴項是間接的，隱藏在代碼抽象層中時，尤其困難重重。

遺憾的是，說到二進制代碼分析，沒有簡單的解決辦法，業界在如何思考基于SBOM的供應鏈安全解決方案方面需要改變觀念。說到封裝的第三方代碼，依賴項列表總是不盡如人意。“信任但驗證”的方法是處理SBOM失敗和降低供應鏈風險的最佳方法。