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可执行文件的完整性。。。。�；；；撼迩绯鍪构セ髡呖梢栽赨EFI执行情形中获得恣意代码执行权限，，，，，该代码可以用于运行恶意软件，，，，，更改启动历程，，，，，直接修补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）或数据执行�；；；ぃ―EP / 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号