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发布漏洞通告
京公网安备11010802024551号