被遗忘的 UEFI Shim：11 个微软签名的旧引导加载器可绕过 Secure Boot

ESET 研究人员发现了 11 个版本号在 0.9 及以下的旧版 UEFI shim 引导加载器。这些二进制文件仍带有微软「Microsoft Corporation UEFI CA 2011」第三方证书的有效签名，因此在任何信任该 CA 的 UEFI 机器上，不论安装的是 Windows 还是 Linux，都可能被滥用来绕过 UEFI Secure Boot。

攻击者若成功利用其中一个易受影响的应用，就能在系统启动阶段执行未受信代码，进而部署 Bootkitty、HybridPetya、BlackLotus 等恶意 UEFI bootkit。ESET 于 2026 年 2 月向 CERT/CC 报告，微软在 6 月 9 日补丁星期二通过 dbx 更新吊销了相关 Authenticode 哈希；CVE 编号为 CVE-2026-8863 与 CVE-2026-10797。

关键点在于：利用并不要求目标机已安装对应发行版。攻击者可以采用类似 BYOVD 的思路，自带易受攻击的旧 shim 副本，放到任意已登记微软第三方 UEFI 证书的系统上。Windows 11 Secured-core PC 默认应关闭该第三方签名选项，但大量普通机器仍信任该 CA。

UEFI Secure Boot 用 db（允许）与 dbx（禁止）校验引导应用。为兼容 Linux，业界使用微软签一次的轻量一级加载器 shim：固件验证 shim 的微软签名后，shim 再用内嵌厂商证书验证 GRUB 2，GRUB 再验证内核。这层间接信任让发行版可快速自签更新，却也把「旧但未吊销」的 shim 变成了长期攻击面。

受影响 shim 背后的二阶段组件（多为 GRUB 2、MokManager 等）时间跨度从 2013 到 2025，其中不少携带已知漏洞。例如 Oracle Linux 相关 shim 信任的旧 GRUB 2 受 CVE-2015-5281 影响：在 UEFI 上可通过精心构造的 multiboot/multiboot2 模块绕过 Secure Boot 限制执行未验证代码。利用几乎不需要内存破坏或复杂 ROP，只要把易受攻击的 shim 与 GRUB 以及自制 multiboot2 镜像放到 ESP，一条 GRUB 命令即可在 Secure Boot 开启时加载执行。

旧 shim 还缺少较新的安全机制。MokListX（MOK 拒绝列表）从 0.9 才开始强制执行；攻击者可把受害者最新 shim 换成更早的微软签名版（例如 Abitti 0.8），仍信任 MokList 中的旧证书却忽略 MokListX。SBAT 从 shim 15.3 才引入，更早版本不读 SbatLevel，可与已被 SBAT 吊销但仍被旧 shim 信任的 GRUB 搭配使用。此外，≤0.9 的 shim 还存在十余年前上游已修、现编号为 CVE-2026-10797 的问题：Authenticode 签名长度在 PE 安全目录与 WIN_CERTIFICATE 中各记一份，吊销检查与验签函数信任的字段不一致，可篡改二阶段签名头以绕过基于证书的吊销（哈希吊销与非内嵌证书路径不受影响）。

证书过期并不能自动解决问题：只要 CA 仍在 db 且二进制未被按哈希写入 dbx，用已过期 CA 签过的引导程序仍可被信任。微软 UEFI CA 2011 于 2026 年 6 月 27 日过期，但在未按哈希吊销前，旧签名依旧有效。

缓解方面，应安装最新微软 dbx 更新；Windows 可用 PowerShell 检查 11 个哈希是否已在 dbx 中，Linux 可通过 LVFS/fwupd 与 uefi-dbx-audit 核对。ESET 强调：危险之处往往不是全新 0-day，而是「无需新漏洞，只要一份仍被信任、尚未吊销的旧 shim 与对 shim 信任链的基本理解」，就足以绕过 Secure Boot。更深的问题是 2017 年 shim-review 之前签过的二进制缺乏完整公开目录，无法系统性地退役；后续还需把同样透明度扩展到非 shim 的第三方 UEFI 应用。