CVE-2020-10713 | GRUB2 BootHole漏洞通告
發布時間 2020-07-300x00 漏洞概述
Eclypsium研究人員在多數Linux系統使用的GRUB2引導程序中發現了一個漏洞將其命名為“BootHole”(CVE-2020-10713),即使啟用了Secure Boot,也可在啟動進程中執行任意代碼。攻擊者可利用該漏洞安裝持久且隱秘的bootkit或惡意引導程序來控制設備。
該漏洞影響使用Secure Boot的系統,即使它們不使用GRUB2。所有簽名的GRUB2均受影響,這意味著幾乎所有的Linux 發行版均受影響。此外GRUB2還支持其它操作系統、內核和管理程序如Xen。這個漏洞還涉及到任何使用具有標準Microsoft Third Party UEFI Certificate Authority的Secure Boot的Windows設備,例如工業、醫療、金融等行業中使用的設備均受影響。該漏洞導致這些設備易遭到例如最近使用惡意UEFI引導程序的攻擊活動。
Eclypsium已和多家行業如OS廠商、計算機制造商和應急響應中心協調披露該漏洞。緩解措施要求簽名和部署新的引導程序,這樣可以防止攻擊者使用老舊、易受攻擊版本。這一過程可能非常漫長,由于組織機構完成修復需要大量時間。
0x01 漏洞詳情
BootHole漏洞是解析grub.cfg文件時在GRUB2中發生的緩沖區溢出。此配置文件是通常位于EFI系統分區中的外部文件,因此可以由具有管理員特權的攻擊者修改,而無需更改已簽名供應商shim和GRUB2 bootloader可執行文件的完整性。緩沖區溢出使攻擊者可以在UEFI執行環境中獲得任意代碼執行權限,該代碼可以用于運行惡意軟件,更改啟動過程,直接修補OS內核或執行惡意代碼。
為了處理來自外部配置文件的命令,GRUB2使用flex和bison從語言描述文件和幫助程序函數生成針對特定域語言(DSL)的解析引擎。
和為每個DSL手動編寫自定義解析器相比,通常認為這是一種更好的方法。但是GRUB2、flex和bison都是復雜的軟件包,具有自己的設計假設,很容易忽略。這些不匹配的設計假設可能會導致易受攻擊的代碼。
flex生成的解析器引擎將此定義包含為令牌處理代碼的一部分:
在這個宏中,生成的代碼檢測到它遇到的令牌太大而無法放入flex的內部解析緩沖區并調用YY_FATAL_ERROR(),這是使用flex生成的解析器的軟件提供的幫助函數。
但是,YY_FATAL_ERROR()GRUB2軟件包中提供的實現是:
它不會停止執行或退出,而只是將錯誤輸出到控制臺并返回到調用函數。不幸的是,在編寫flex代碼時就期望YY_FATAL_ERROR()不會再返回任何調用。這導致yy_flex_strncpy()被調用,并將源字符串從配置文件復制到一個太小而無法容納它的緩沖區中。
除了這個特定的路徑之外,flex生成的代碼中的許多其他地方也期望對YY_FATAL_ERROR()的任何調用永遠不會返回,并且在期望被破壞時執行不安全的操作。API的生產者和消費者之間的假設不匹配是一個非常常見的漏洞來源。
最終,通過為配置文件提供輸入令牌,解析器無法處理這些太長的令牌,此緩沖區溢出將覆蓋堆中的關鍵結構。這些被覆蓋的字段包括解析器結構元素,它可以用作任意的write-what-where原語,以獲取任意代碼執行并劫持引導過程。
還要注意的是,UEFI執行環境沒有地址空間布局隨機化(ASLR)或數據執行保護(DEP / NX)或其他系統中常見的緩解漏洞的技術,因此,此類漏洞很容易利用,堆是完全可執行的,無需構建ROP鏈。
鑒于GRUB2 解析配置文件的方法中存在一個弱點,攻擊者可以執行任意代碼,繞過簽名驗證。BootHole漏洞可被用于安裝可持久和隱秘的bootkit或者即使在啟用Secure Boot 的情況下也可運行的惡意引導程序。攻擊者能夠在操作系統之前運行惡意代碼并控制操作系統的加載方式、直接修復操作系統、甚至使引導程序修改OS鏡像。
所有從grub.cfg文件中讀取命令的GRUB2 簽名版本均易受攻擊,影響所有Linux 發行版。截至目前,已有80多個shim受影響。除了Linux 系統外,任何使用具有標準微軟UEFI CA的Secure Boot的系統也受該漏洞影響。因此,研究人員認為當前使用的大多數系統,以及大量基于Linux 的OT 和IoT系統,均可能受這些漏洞的影響。
另外,任何依賴UEFI Secure Boot 的硬件根信任機制均可被繞過。
0x02 處置建議
受影響廠商發布安全公告和更新:
? Microsoft
? Security advisory
? https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200011
? UEFI Forum
? Updated Revocation List
? https://uefi.org/revocationlistfile
? Debian
? Security advisory
? https://www.debian.org/security/2020-GRUB-UEFI-SecureBoot
? Canonical:
? Security advisory
? https://ubuntu.com/security/notices/USN-4432-1
? KnowledgeBase article
? https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass
? Red Hat
? Customer documentation
? https://access.redhat.com/security/vulnerabilities/grub2bootloader
? CVE information
? https://access.redhat.com/security/cve/cve-2020-10713
? Vulnerability response article
? https://access.redhat.com/security/vulnerabilities/grub2bootloader
? SUSE
? Security advisory:
? https://www.suse.com/c/suse-addresses-grub2-secure-boot-issue/
? Knowledge Base article:
? https://www.suse.com/support/kb/doc/?id=000019673
? HP
? Security advisory
? HPSBHF03678 rev. 1 – GRUB2 Bootloader Arbitrary Code Execution:https://support.hp.com/us-en/document/c06707446
? HPE
? Security advisory
? https://techhub.hpe.com/eginfolib/securityalerts/Boot_Hole/boot_hole.html
? VMware
? Knowledge Base article
? https://kb.vmware.com/s/article/80181
? Upstream Grub2 project
? GRUB2 Git Repository:http://git.savannah.gnu.org/gitweb/?p=grub.git&view=view+git+repository
? GRUB Developer Mailing List:https://lists.gnu.org/mailman/listinfo/grub-devel/
需要注意的是和UEFI相關的更新曾導致設備不可用,因此廠商需要非常謹慎。如果在更新的Linux引導加載程序和shim之前更新了吊銷列表(dbx),則將不會引導系統。
更復雜的情況是,企業災備機制也會遇到此問題,另外,當硬件故障而需要進行設備更新時,相同型號的新系統可能已經應用了dbx更新,并且在嘗試引導先前安裝的操作系統時會失敗。
建議:
1、監控引導程序分區(EFI程序分區)的內容,這將為其余的過程節省時間,并有助于確定受影響的系統;
2、繼續更新系統,以減少攻擊的可能性。特別是更新后,舊的引導程序建議刪除。它包括急救盤、安裝程序、企業黃金鏡像、虛擬機或其它可引導媒介;
3、測試撤銷列表更新。確保測試的是在使用的固件版本和型號。
4、要解決此漏洞問題,首先要部署吊銷更新。
5、聯系供應商,確認他們正在解決此問題。
Eclypsium具有可用的powershell和bash腳本,用于檢測此dbxupdate吊銷的引導程序,參考鏈接:https://github.com/eclypsium/BootHole/。
0x03 相關新聞
https://www.zdnet.com/article/boothole-attack-impacts-windows-and-linux-systems-using-grub2-and-secure-boot/#ftag=RSSbaffb68
0x04 參考鏈接
https://eclypsium.com/2020/07/29/theres-a-hole-in-the-boot/
0x05 時間線
2020-07-29 Eclypsium發布報告
2020-07-30 VSRC發布漏洞通告