Binarly REsearch 團隊近日深入研究了最近的 OpenSSL 安全更新給 UEFI 固件供應鍊生态系統帶來怎樣的影響以及 OpenSSL 版本在固件環境中是如何廣泛使用的。研究結果不容樂今天伊人飄雪要和大家分享的是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.2j
DxeCore, Tcg2Dxe, TcgDxe, VariableSmm, SecurityStubDxe, IpSecDxe, IScsiDxe, Setup, PlatformMilestoneHookDxe, PlatformMilestoneHookSmm, LenovoTpmConfigDxe, PlatformInit, PeimBoardInit, PeimBoardInit, PeimBoardInit, Tcg2Pei, TcgPei, PlatformInitPreMem, LenovoPcdInit, LenovoVerifiedBootPei
1.0.0a
FlashUtilitySmm, LenovoCryptService, LenovoCryptServiceSmm, LenovoSvpManagerSmm, LenovoSetupAutomationSmm, LenovoSetupUnderOsSmm, LenovoSecureKeySmm, LenovoDriveEraseSmm
0.9.8zb
InfineonTpmUpdateDxe
我們可以看到，同一個固件二進制包中至少使用了三個不同版本的 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 數據，不妨看看不同版本與各大企業廠商的設備上的發布日期有怎樣的聯系。
設備廠商
發布日期
聯想和戴爾
0.9.8l
05-Nov-2009
聯想、戴爾和惠普
0.9.8w
24-Apr-2012
聯想和惠普
06-Aug-2014
聯想
0.9.8zd
08-Jan-2015
0.9.8ze
15-Jan-2015
0.9.8zf
19-Mar-2015
01-Jun-2010
1.0.2d
09-Jul-2015
1.0.2f
28-Jan-2016
1.0.2g
01-Mar-2016
1.0.2h
03-May-2016
26-Sep-2016
1.0.2k
26-Jan-2017
1.0.2u
20-Dec-2019
1.1.0b
1.1.0g
02-Nov-2017
1.1.0h
27-Mar-2018
1.1.0j
20-Nov-2018
1.1.1d
10-Sep-2019
1.1.1l
24-Aug-2021
戴爾
1.1.0e
16-Feb-2017
1.1.1n
15-Mar-2022
我們從 Binarly OpenSSL 的研究數據中可以看出，固件常常使用多個版本的 OpenSSL。其背後的原因是，第三方代碼的供應鍊依賴它們各自的代碼庫，而設備固件開發人員常常無法獲得這些代碼庫。這就增加了供應鍊的複雜性。大多數 OpenSSL 依賴項作為庫靜态鍊接到特定的固件模塊，這些模塊創建編譯時依賴項，如果沒有深入分析代碼的功能，就很難識别這些依賴項。在過去，第三方代碼依賴項的問題不是在編譯代碼層面就能輕松解決的問題。
行業目前采取的做法是為單獨的模塊生成散列，與特定的版本版本号相關聯，以便連接 SBOM 層面的依賴項列表。這種做法适用于開源項目（比如用于驗證的 Sigstore 項目），但面對閉源生态系統，它總是以失敗告終。雖然散列提供了完整性信息，但無法為閉源項目保證 SBOM 内容和完整性。從這個意義上說，涉及到在二進制層面進行驗證的編譯代碼時，我們迫切需要一個額外的 SBOM 驗證層，即與廠商提供的實際 SBOM 相匹配的第三方依賴項信息列表。
完整性提供不了代碼級别的可見性，根據二進制模塊的散列确定依賴項的範圍很困難。當依賴項是間接的，隐藏在代碼抽象層中時，尤其困難重重。
遺憾的是，說到二進制代碼分析，沒有簡單的解決辦法，業界在如何思考基于 SBOM 的供應鍊安全解決方案方面需要改變觀念。說到封裝的第三方代碼，依賴項列表總是不盡如人意。" 信任但驗證 " 的方法是處理 SBOM 失敗和降低供應鍊風險的最佳方法。
關于UEFI固件使用OpenSSL暴露了軟件材料清單（SBOM）的弱點，戴爾、惠普和聯想中招就介紹完了，您有什麼想法可以聯系伊人飄雪。
