严重的 BootHole 漏洞影响所有 Linux 发行版和 Windows 系统（详细分析）

Eclypsium 公司发现，GRUB2 引导程序 (bootloader) 中存在“BootHole” 漏洞，导致使用 Secure Boot 的 Windows 和 Linux 设备易受攻击。所有使用具有 Secure Boot 的 GRUB2 的操作系统必须发布新的安装程序和引导程序。

引言

Eclypsium公司的研究人员在多数Linux系统使用的GRUB2 引导程序中发现了一个漏洞且将其命名为“BootHole”，它可在启动进程中获得任意代码执行的权限，即使在启动Secure Boot 的情况下也不例外。利用该漏洞的攻击者可以安装持久且隐秘的bootkit或恶意引导程序，使其能够几乎完全控制受害者设备。该漏洞影响使用Secure Boot 的系统，即使它们不使用GRUB2。几乎所有签名的GRUB2 均易受攻击，也就是说几乎所有的Linux 发行版均受影响。另外，GRUB2还支持其它操作系统、内核和管理程序如Xen。这个问题还延伸至任何使用具有标准Microsoft Third Party UEFI Certificate Authority 的Secure Boot的Windows 设备，因此大多数笔记本电脑、桌面、服务器和工作站、网络设备和工业、医疗、金融和其它行业中使用的其它特殊用途的设备均受影响。该漏洞使得这些设备易遭如最近使用恶意UEFI 引导程序的威胁行动者的攻击。Eclypsium已和多家行业实体如OS厂商、计算机制造商和应急响应中心负责任地协调披露该漏洞。缓解措施要求签名和部署新的引导程序，且应当撤销易受攻击的引导程序，阻止攻击者使用老旧、易受攻击版本。这一过程可能非常漫长，组织机构完成修复需要大量时间。

背景：Secure Boot、GRUB2 和CAS

SecureBoot 可以是进行非常深入探讨且具有技术性的话题。我们此处的目标是给出和这项研究相关的关键概念的高层介绍，而不会太深入说明所有细节。对更多细节感兴趣的读者可参阅相关资料。

启动进程面临的威胁

启动进程对任何设备的安全性从根本上起到非常重要的作用。它依赖多种固件来控制设备的多种组件和外围设备如何被初始化并最终协调操作系统本身的加载。总体而言，代码加载得越早，它的权限越高。如果该进程遭攻陷，那么攻击者能够控制操作系统的加载方式并攻陷所有高层安全控制。研究人员最近发现，在野勒索软件将恶意EFI 引导程序作为在启动时控制机器的方法。此前有不少威胁行动者使用篡改了遗留 OS 引导程序的恶意软件，包括APT 41 Rockboot、LockBit、FIN1Nemesis、MBR-ONI、Petya/NotPetya和Rovnix。更多内容，可参考如下链接：https://github.com/abazhaniuk/firmware-security-training/blob/master/BIOS-UEFI-Security.2-BootkitsSecureBoot.pdf

UEFI Secure Boot

UEFI Secure Boot 最初是由UEFI Forum 开发的，用于保护引导进程免受这类攻击。虽然不同环境具有不同的secure boot 实现方式，但UEFI Secure Boot 是个人电脑和服务器的标准实现。它的目的是通过在每个固件和软件运行前执行加密检查的方式，阻止恶意代码被引入引导进程。引导进程不会执行任何未被认为是合法的代码。Secure Boot 在引导进程中按要求使用加密签名来验证代码的完整性。这个进程中牵涉两个关键的数据库：批准组件的AllowDB (db) 和易受攻击或恶意组件的Disallow DB (dbx)，包括固件、驱动和引导程序。修改这些数据库的权限受Key Exchange Key (KEK) 的保护，而后者由Platform Key (PK) 予以验证。尽管PK被用作平台更新的根信任，但它并非引导进程的组成部分。在引导时用于验证所加载可执行文件签名的是dbx、db和KEK。

更多关于Secure Boot 的内容可见：http://www.c7zero.info/stuff/Windows8SecureBoot_Bulygin-Furtak-Bazhniuk_BHUSA2013.pdf

信任链和 GRUB2

接着，OEM必须管理可签名受Secure Boot Database 信任的代码清单。每个OEM 不必管理来自所有可能固件、驱动或OS 提供商的证书，SecureBoot 允许使用集中的证书颁发机构(CA)。微软的第三方UEFI CA 提供了Secure Boot 的行业标准签名服务。简言之，第三方可以向微软提供其代码，而微软通过Microsoft CA 来验证和签名代码。这就建立了一种信任链，它只要求OEM 平台注册Microsoft 第三方UEFI CA，启用Secure Boot 时默认引导第三方安装媒介和操作系统。它包括从非微软操作系统如Linux 签名引导程序。在几乎所有的现代Linux 发行版中，GRUB(Grand Unified Bootloder) 都是向操作系统加载并传输控制的引导程序。本文中所提到的GRUB 均指GRUB2，是对常被称为“GRUB Legacy” 的前一个版本的完全重写。从2009年开始，所有广泛使用的Linux 发行版都开始使用GRUB2.GRUB Legacy 已被弃用，通常仅出现在更老旧的版本中。由于许可不兼容性带来的法律问题，开源项目和秋天第三方构建了一个小型应用程序，名为 “shim”，包含用于验证并运行引导程序 (GRUB2) 的供应商证书和代码。该供应商的 shim 通过微软第三方UEFI CA 进行验证，然后shim 使用内嵌在本身的供应商证书加载并验证GRUB2 引导程序。

更多关于微软UEFI CA 在引导进程中的角色可见：https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-secure-boot-key-creation-and-management-guidance

Secure Boot 面临的挑战

和任何技术进程一样，SecureBoot 并非完美无瑕。该进程牵涉很多代码，而其中出现任何一个漏洞都会成为导致攻击者绕过SecureBoot 的失败点。另外，尽管UEFI Secure Boot 试图为引导进程提供某种完整性保证，但该硬件的其它不当配置或缺失的保护特征可破坏引导的安全性。其中一个例子就是使用如PCIe Microblaze 的DMA 攻击。此外，如本文将要战士的那样，引导进程中的漏洞可导致任意代码执行后果，可使攻击者控制引导进程和操作系统，即使在secure boot 签名得到验证的情况下也不例外。攻击者还能使用易受攻击的引导程序攻击系统。例如，如果合法引导程序存在漏洞，那么恶意软件就能将该设备现有的引导程序替换为易受攻击版本。该引导程序将得到 Secure Boot 的允许并使得恶意软件完全控制系统和 OS。缓解这个问题要求非常积极地管理用于查找恶意或易受攻击代码的 dbx 数据库。

另外，Secure Boot 进程的更新和修复方案尤其复杂，可能面临使设备崩溃的风险。引导程序一般牵涉多个角色和组件，包括设备OEM、操作系统供应商和管理员。鉴于引导进程的本质，任何问题都很可能使设备不可用。因此，Secure Boot 的更新进程一般比较缓慢而且要求进行大量行业测试。

通过 GRUB2 打破 Secure Boot

在分析过程中，研究人员在 GRUB2 解析 GRUB2 配置文件 (grub.cfg) 的过程中发现了一个缓冲溢出漏洞。注意，该 GRUB2 配置文件是一个文本文件且一般不会被其它文件和可执行文件签名。该漏洞使得能够在 GRUB2 中执行任意代码，因此可以控制操作系统的引导进程。结果，攻击者能够修改 GRUB2 配置文件的内容，以确保在加载操作系统之前会运行攻击代码。如此，攻击者在设备上获得持久性。这类攻击要求攻击者具有提升的权限。然而，它可使攻击者具有其它的强大的提升权限并在设备上获得可持久性，即使在所有加载的可执行文件上启用了Secure Boot 和正确地执行签名验证也不例外。Secure Boot 的一个明确的设计目标是，即使以管理员权限运行，但也要通过禁用 Secure Boot 或修改引导链的方式，阻止越权代码获得其它权限和操作系统加载前的持久性。除了在GRUB2可执行文件上执行签名验证后，还添加自定义代码执行grub.cfg 配置文件的签名验证的可引导工具厂商外，所有从外部grub.cfg配置文件中加载命令的GRUB2 版本均易受攻击。因此，它要求为所有Linux 版本发布新的安装程序和引导程序。厂商需要发布引导程序shim 的新版本，并由微软第三方UEFI CA 签名。有必要注意的是，在所有受影响版本都被加入dbx 撤销列表之前，攻击者能够使用易受攻击的shim 版本和GRUB2 攻击系统。也就是说，所有信任微软第三方UEFI CA 的设备在此期间均易受攻击。除了使用由微软第三方UEFI CA 签名的shim 外，一些控制设备中硬件和软件栈的OEM 使用自己硬件中提供的密钥直接签名GRUB2。他们同时需要更新并撤销这些系统之前易受攻击的GRUB2。该漏洞的编号是CVE-2020-10713，名称是“GRUB2：构造grub.cfg 文件在引导进程中执行任意代码”，CVSSv2 评分为8.2（高危）/CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H。

漏洞分析

该漏洞是在解析grub.cfg 文件时在GRUB2 中发生的一个缓冲溢出漏洞。该配置文件是一个外部文件，通常位于EFI 系统分区中，因此能够在无需修改索签名厂商shim和GRUB2引导程序可执行文件的情况下，遭具有管理员权限的攻击者修改。该缓冲溢出漏洞可使攻击者在UEFI 执行环境中获得任意代码执行权限，从而运行恶意软件、修改引导进程、直接修复OS 内核或执行任意数量的其它恶意动作。为深入分析该漏洞，研究人员仔细查看了代码在内部如何运行的情况。为了处理外部配置文件的命令，GRUB2使用flex和bison从语言描述文件和帮助函数中生成用于特定域语言(DSL) 的解析引擎。它通常被认为是比为每个DSL 手动编写自定义解析器的更好方法然而，GURB2、flex和bison 都是复杂的软件数据包，其自身的设计假设容易被忽略。而这些匹配不当的设计假设可导致易受攻击代码的出现。Flex生成的解析引擎包括令牌处理代码的define as 部分：

#define YY_DO_BEFORE_ACTION \    yyg->yytext_ptr = yy_bp; \    yyleng = (int) (yy_cp - yy_bp); \    yyg->yy_hold_char = *yy_cp; \    *yy_cp = '\0'; \    if ( yyleng >= YYLMAX ) \        YY_FATAL_ERROR( "token too large, exceeds YYLMAX" ); \    yy_flex_strncpy( yytext, yyg->yytext_ptr, yyleng + 1 , yyscanner); \    yyg->yy_c_buf_p = yy_cp;

在这个宏中，生成的代码检测它遇到一个太大而难以适合flex 内部解析缓冲区并调用YY_FATAL_ERROR() 的令牌。YY_FATAL_ERROR()是使用由flex 生成解析器的软件的帮助函数。然而，GRUB2软件包中提供的YY_FATAL_ERROR()函数实现是：

#define YY_FATAL_ERROR(msg)                     \  do {                                          \    grub_printf (_("fatal error: %s\n"), _(msg));     \  } while (0)

它并未停止执行或退出，只是向控制面板打印了一个错误并返回到调用函数。遗憾的是，flex代码编写的例外是任何YY_FATAL_ERROR均不会返回。这就导致yy_flex_strncpy()被调用，且从配置文件将源字符串复制到一个太小而无法包含它的缓冲区中。

除了这个特定路径外，整个由flex生成的代码的其它地方也期待任何对YY_FATAL_ERROR() 的调用永远不会返回，而在这个例外被打破时会执行不安全的操作。API生产者和消费者之间匹配不当的假设是一个非常常见的漏洞来源。最后，通过提供输入令牌太长而无法被解析器处理的配置文件，这个缓冲溢出覆写了堆中的关键结构。这些被覆写的字段包括多个内部解析器结构元素，它们可被用作任意write-what-where 原语，用于获得任意代码执行的权限并劫持引导进程。

另外还要注意，UEFI执行环境并不具备地址空间布局随机化(ASLR) 或数据执行防御(DEP/NX) 或其它常见于现代操作系统中的利用缓解技术，因此创建这种漏洞的exploit 极其容易。该堆完全是可执行的，无需构建ROP 链。最后，该漏洞并非特定于基础架构，而是存在于一个常见的代码路径中，另外可以使用GRUB2 的签名ARM64 版本得到证实。

其它漏洞

GRUB2中曾出现多个漏洞，可导致任意代码执行后果但影响范围要小得多。2019年4月，卡巴斯基Rescure Disk 如何使用GRUB2 的方式中存在一个漏洞且被公开披露。2020年2月，就在修复版本发布6个多月后，微软发布更新，通过更新UEFI 撤销列表(dbx) 以拦截已知易受攻击的卡巴斯基一电脑程序的方式，删除了所有Windows 系统中的易受攻击的引导程序。遗憾的是，它导致多个厂商遭遇例外错误，包括设备崩溃等，因此该更新被删除。2020年3月，Dmytro Oleksiuk 披露称某些HPE ProlIant 服务器中包含由HP CA 签名的一个GRUB2 版本，可导致使用“insmod” 命令加载未签名代码。该漏洞编号为CVE-2020-7205，在7月29日得到修复。Canonical安全团队还在GRUB2 代码中发现了其它漏洞：

CVE-2020-14308 GRUB2：grub_malloc并未验证分配大小，导致算术溢出，最终导致基于堆的缓冲溢出（中危，CVSS评分6.4）
CVE-2020-14309 GRUB2：grub_squash_read_symlink中的整数溢出漏洞，可导致堆溢出（中危，CVSS评分5.7）
CVE-2020-14310 GRUB2：read_section_from_string中的整数溢出漏洞，可导致堆溢出（中危，CVSS评分5.7）
CVE-2020-14311 GRUB2：grub_ext2_read_link中的整数溢出漏洞，可导致堆溢出（中危，CVSS评分5.7）
CVE-2020-15705 GRUB2：但grub直接在secureboot 情况下（无shim）被引导时，避免加载未签名内核（中危，CVSS评分6.4）
CVE-2020-15706 GRUB2 脚本：在执行过程中，重定义函数时避免释放后使用漏洞（中危，CVSS评分6.4）
CVE-2020-15707 GRUB2：initrd大小处理中的整数溢出漏洞（中危，CVSS评分5.7）

鉴于整个生态系统更新/删除的难度很大，因此强烈建议六个月后再执行此类操作。为此，Oracle、RedHat、Canonical、VMware和Debian安全团队使用静态分析工具和手动审计的方法，在整个代码库中识别和修复其它数十个漏洞和危险操作，这些漏洞尚未分配CVE 编号。

影响

鉴于GRUB2 解析配置文件的方法中存在一个弱点，攻击者可以执行任意代码，绕过签名验证。BootHole漏洞可被用于安装可持久和隐秘的bootkit 或者即使在启用Secure Boot 且它运行正常的情况下也可运行的恶意引导程序。它导致攻击者能够在操作系统之前运行恶意代码并控制操作系统的加载方式、直接修复操作系统、或者甚至使引导程序修改OS 镜像。它实际上使攻击者具有对受害者设备的无限制访问权限。最近，研究人员发现在野出现恶意一电脑程序，而该漏洞将使设备易受此类攻击。所有从外部grub.cfg 文件中读取命令的GRUB2 签名版本均易受攻击，影响所有Linux 发行版。截至目前，已有80多个shim受影响。除了Linux 系统外，任何使用具有标准微软UEFI CA 的Secure Boot 的系统均受该漏洞影响。因此，研究人员认为当前使用的大多数系统，包括服务器和工作站、笔记本电脑和桌面，以及大量基于Linux 的OT 和IoT系统，均可能受这些漏洞的影响。另外，任何依赖UEFI Secure Boot 的硬件信任根机制均可被绕过.

缓解措施

完全缓解需要多个实体的协调：受影响的开源项目、微软、受影响系统所有人等等。缓解措施包括：

更新GRUB2
Linux版本和使用GRUB2的其它厂商需要更新安装程序、引导程序和shim。
微软第三方UEFI CA 需要签名新的shim。
受影响系统的管理员需要更新操作系统版本和安装程序镜像，包括灾难备份媒介。
最后，需要更新受影响系统固件中的UEFI 撤销列表(dbx)，组织在引导过程中运行易受攻击代码。

在7月29日的协调发布日(CRD)，如下受影响厂商将发布安全公告和更新：

Microsoft
UEFISecurity Response Team (USRT)
Oracle
RedHat (Fedora and RHEL)
Canonical(Ubuntu)
SuSE(SLES and openSUSE)
Debian
Citrix
VMware
多家OEM
软件厂商（包括安全软件）也受该漏洞影响，也需要更新引导程序

然而，撤销进程的完整部署将可能非常缓慢。和UEFI 相关的更新曾导致设备不可用，因此厂商需要非常谨慎。如撤销列表(dbx) 在既定Linux 引导程序和shim 更新前进行了国内性能，则操作系统不会被加载。因此，对撤销列表的更新将持续进行，以阻止尚未被更新的系统崩溃。而且也存在难以更新dbx 的情况，如双重启动或已取消配置的机器。但OS安装或启动时，需要在系统应用删除操作前更新引导程序和OS。更复杂的情况是，企业灾难备份进程会遭遇问题：如果dbx更新已应用，则得到批准的恢复媒介不再在系统上启动。除了硬件失败需要刷新设备的情况，同样模型的新系统可能已经应用了dbx 更新，并且当试图引导之前安装的操作系统时会失败。在向企业系统推送dbx 更新前，必须同时更新和验证恢复和安装媒介。微软将发布签名dbx 更新，应用于系统以阻止shim 加载易受攻击的GRUB2 版本。鉴于系统可能崩溃或运行或恢复工作流崩溃，这些dbx 更新将首先为利益相关方推出，手动应用到系统而非自动推送删除条目。它可使IT专业人员、爱好者和其他人有机会在各自系统上测试删除更新并在手动撤销前找到任何问题。另外，组织机构需要确保具有监控UEFI 引导程序和固件并验证系统中UEFI 配置（包括撤销列表）的能力。组织机构还应该在更新发布时测试恢复能力，包括UEFI设置中的“重置到出厂默认状态”功能。这将确保如果设备在更新后出现问题，也可以使其恢复。最后，组织机构应该持续监控系统中使用易受攻击引导程序感染或损害系统的威胁和勒索软件。

建议

1、马上开始监控引导程序分区（EFI程序分区）的内容。它将为进程的其它部分赢得时间并有助于识别你所在环境中的受影响系统。2、继续在桌面、笔记本电脑、服务器和设备中如常安装OS 更新。攻击者可以利用OS和应用程序中的提权缺陷利用该漏洞，因此非常有必要阻止攻击者获得对系统的管理员访问权限。后续安装删除更新后，老旧的引导程序应当会停止运作。它包括急救盘、安装程序、企业黄金镜像、虚拟机或其它可引导媒介。3、测试撤销列表更新。确保测试的是在使用的固件版本和型号。它可能有助于首先更新至最新固件版本，以减少测试用例的数量。4、要解决这个漏洞问题，你需要部署删除更新。确保所有的可引导媒介首先接收到OS更新，每次仅像少量设备推出，并在这个过程中集成测试经验。5、和第三方厂商一起验证并解决问题。第三方应当提供服务/解决方案的应用能力以及解决这个高危漏洞的修复计划。

结论

虽然多数用户很容易认为安全的启动进程 (Secure Boot) 是理所当然的，其实它是多数设备安全性的根基。一旦遭攻陷，攻击者实际上鞥能够完全控制设备、操作系统及其应用和数据。如这项研究所展示的那样，当引导进程中出现问题时，它会对很多设备类型产生深远影响。我们将持续跟踪事态进展，建议用户和管理员密切关注硬件厂商、微软MSRC 和相关开源项目发布的警告和通知消息。参考资料：