2026 年 7 月 15 日，Ars Technica 发表了一篇让安全社区坐不住的报道：微软的 Secure Boot 机制在过去 14 年中，有 13 年处于可被简单绕过的状态。不是零日漏洞，不是国家级攻击者的高级持久威胁——只是一些被遗忘的、仍然持有微软有效签名的旧版引导程序。
发现者是斯洛伐克安全公司 ESET 的研究员 Martin Smolár。他在排查 UEFI 固件镜像时，找到了 11 个来自 2013 年左右、早已被确认存在漏洞的 shim 引导程序。这些程序本该在漏洞公开后被微软撤销签名——但实际上从未被撤销。它们就像被遗忘在武器库里的过期门禁卡，拿着它的人不需要撬锁，刷卡就能进。
「The whole ecosystem is somewhat broken and needs a reboot。」固件安全专家、runZero CEO HD Moore 在采访中说。
Secure Boot 到底保护了什么
Secure Boot 是 UEFI 固件标准中的一个安全机制，由微软在 2012 年推动引入。它的核心逻辑不复杂：电脑开机时，固件只加载持有可信数字签名的代码。从主板固件到操作系统内核，整条启动链上的每一个环节都必须验证签名。理论上，这能阻止 bootkit——一种在操作系统启动前就潜入的恶意固件。
现实中的 bootkit 威胁并非学术假设。2018 年，俄罗斯国家黑客使用的 LoJax bootkit 被曝光；2020 年出现了 MosaicRegressor；2022 年有 CosmicStrand；2023 年的 BlackLotus 甚至在已打补丁的 Windows 11 系统上绕过了 Secure Boot。大多数 bootkit 需要攻击者短暂物理接触目标设备——这正是 Secure Boot 明确声称要防御的威胁模型。
问题在于，Secure Boot 的信任链依赖一个前提：所有被签名的代码都是安全的，不安全代码的签名会被撤销。当这个前提崩塌，整条链就没有意义了。
Shim：为了兼容而打开的门
要理解这次事件的根源，需要先了解 Secure Boot 生态中的一个特殊角色：shim。
Secure Boot 的设计初衷是为 Windows 设备提供保护。在纯 Windows 环境中，微软的 UEFI 引导加载器是唯一的信任锚点——固件只信任微软的签名，Windows 引导器再验证后续的所有组件。这个模型简单且封闭。
但 Linux 也需要在开启 Secure Boot 的机器上启动。解决方案就是 shim——一个由微软签名的轻量引导程序，它充当固件和 Linux 引导器（通常是 GRUB2）之间的中间层。shim 自己通过了 Secure Boot 的签名验证后，转而信任内嵌的 Linux 发行版证书，用这些证书来验证 GRUB 和内核。
可以把 shim 理解为 Secure Boot 围墙上的一扇门。门本身通过了安全检查（微软的签名），但门后面通向哪里由发行版自己决定。这个设计本身是 Secure Boot 生态兼容 Linux 所必需的——但也正是这个设计，让 shim 变成了整个系统中最薄弱的环节。
11 个未被撤销的门禁卡
ESET 发现的 11 个 shim 分别来自 Red Hat、OpenSUSE、Oracle 等 Linux 发行版，以及 PC-Doctor Finland 等第三方软件商。不少是在 shim 0.9 甚至更早版本的基础上构建的——那个年代还没有 SBAT（Secure Boot Advanced Targeting）机制，也没有 MOK 拒绝列表（Machine Owner Key denylist）。个别 shim 内嵌的第二阶段引导器本身就存在已知漏洞——比如 Oracle 的 shim 签名的某个二进制文件可以被 CVE-2015-5381 攻击，Smolár 评估其利用难度为「低」。
关键的时间线让人不安：这些 shim 中至少有一个来自 2013 年。从那时起，它们就在互联网上公开可获取，带着微软的有效签名，从未被撤销。十三年——足够让一代硬件退役，足够让几个操作系统版本成为历史，却不够让微软把这些已知有漏洞的组件加入撤销列表。
为什么没有撤销？Smolár 的分析指向一个结构性原因：Secure Boot 的撤销机制过于复杂。UEFI 固件中有两个数据库——db（允许列表）和 dbx（禁止列表）。要阻止一个组件启动，必须把它加入 dbx。但 dbx 只有 32KB 的存储空间，在 Linux 引导链中可能涉及大量需要列入黑名单的哈希值。
微软后来引入了 SBAT 和 SVN（Secure Boot Security Version Number）作为补充——不撤销单个文件哈希，而是按版本号撤销。但这些机制在早期 shim 中根本不存在。旧 shim 既没有 SBAT 支持来拒绝自己的旧版本，也没有 MOK 拒绝列表来阻止已知有问题的发行版证书。
更尴尬的是，即使签名这些 shim 的微软「Microsoft Corporation UEFI CA 2011」证书已经在 2026 年 6 月 27 日过期，这仍然不足以阻止攻击——证书过期意味着新硬件不再预装它，但已经在设备固件中的证书仍然被信任，仍然会放行旧 shim。
不需要新漏洞的攻击
Smolár 的判断可能是整个事件中最让人警醒的一句话：「让这些旧 shim 变得危险的，不是一个新的漏洞。是不需要新漏洞就能绕过 UEFI Secure Boot。攻击者不需要复杂的利用原语——只需要一份旧的、仍被信任的、未被撤销的 shim 二进制文件，以及对 UEFI shim 工作机制的基本理解。」
攻击场景相当直接：拿到管理员权限的攻击者，或者有物理接触的人，把受害者机器上的现有引导器替换成一个易受攻击的旧版 shim。因为旧 shim 有微软的有效签名，Secure Boot 会放行。然后攻击者利用 shim 本身的漏洞，或者 shim 信任的旧发行版证书，加载恶意代码，在操作系统启动之前获得执行权。
这种恶意代码可以做什么？安装持久化的 bootkit，在每次开机时运行，即使操作系统被重装或硬盘被更换也无法清除。这就是 Secure Boot 当初被设计来阻止的事情。攻击者还可以使用「自带漏洞驱动」（BYOVD）的技巧——利用 shim 信任的旧证书加载一个已知有漏洞的驱动，然后通过驱动漏洞获得内核级执行权限。
微软在 2026 年 6 月的例行补丁（Patch Tuesday）中最终撤销了这些 shim，但前提是 ESET 在今年 2 月通过 CERT 协调中心向微软报告之后。如果你是一个每月准时安装 Windows 更新的用户，你的机器现在安全了。Linux 用户则需要检查自己的发行版是否已经同步了 dbx 更新——可以用 uefi-dbx-audit 脚本来验证撤销状态。
信任锚点出了问题
如果把这次事件放在更大的安全图景里看，它暴露了两个系统性问题。
第一个是密钥管理的规模不匹配。微软作为 UEFI 生态中事实上的根信任机构，需要对所有经过其签名的第三方引导组件负责——但在实际操作中，签完之后的长期维护和撤销跟踪似乎并没有一个可审计的流程。11 个已知有漏洞的组件在网络上一躺就是十年，直到外部研究员把它们找出来。
第二个是「安全机制本身变成攻击面」的经典困境。Secure Boot 的复杂性——db、dbx、SBAT、SVN、MOK、shim 证书链——是一层套一层的防护，但每一层都是代码，而代码可能有缺陷。当防护层数多到连设计者自己都可能漏掉某些组件的撤销时，增加复杂性反而降低了安全性。
HD Moore 的批评更根本：「这是对整个 Secure Boot 模型的一次有力反驳。」他指出的问题包括：微软成为整个 UEFI 平台事实上的根信任、保护机制无法充分扩展、顶层证书过期后组件仍可启动。他的结论是生态需要「重启」——在信任模型设计层面上的重新思考，不只是一次软件补丁。
这些质疑指向一个尚未被认真回答的问题：当一个安全机制的复杂性超出了维护者能合理管理的范围，它还算安全吗？十三年无人发现的事实暗示答案可能是否定的——但这并不意味着 Secure Boot 应该被抛弃。它的替代方案——没有启动时完整性验证——更不安全。真正的问题在于，一个信任体系的维护成本，不能只靠外部研究员的偶然发现来做最后的防线。
参考链接：
- Ars Technica 报道（Dan Goodin）
- ESET Research 技术分析（Martin Smolár）
- The Hacker News 报道
- SC World 报道
- BankInfoSecurity 报道