Microsoft’s Secure Boot has been broken for a decade and no one noticed until now

微软的“安全启动”机制已存在十年漏洞，直到现在才被发现 - Ars Technica

安全启动机制亟需重启

微软的“安全启动”机制已存在十年漏洞，直到现在才被发现

微软未能撤销的旧版“中间件”导致安全启动机制被轻易绕过

Dan Goodin

–

2026年7月14日 下午6:20

|

56

手指即将按下电源按钮。硬件设备概念图。

图片来源：Getty Images

按钮

文字设置

面板

正文文字

尺寸

小号

标准

大号

宽度

*

宽屏

链接

橙色

• 仅限订阅者

了解更多

最小化至导航栏

微软发明的行业标准安全启动机制，本应用于保护Windows及后续Linux设备免受固件感染，但该机制在其14年历史中的13年里都极易被绕过。安全公司ESET的研究人员在发现11个已知存在缺陷但仍由软件公司签名的固件镜像（其中至少有一个来自2013年）后得出了这一结论。

这些镜像被称为"中间件"，最初设计用于将安全启动扩展至Linux设备和实用软件。攻击者只需使用新手黑客即可掌握的简单技术，就能利用这些被遗忘的旧版中间件完全绕过嵌入在设备主板UEFI（统一可扩展固件接口）中的保护机制。这一漏洞源于微软未能在发现这些中间件存在漏洞后撤销其公开可用的镜像。

威胁同时影响Windows和Linux用户

该威胁同时影响Windows和Linux用户，因为这种中间件可以安装在运行这两种操作系统的设备上。从那里，攻击者可以破坏数字签名固件的强制链，安装恶意固件。这种恶意固件会在启动过程早期加载，并在操作系统重新安装或更换硬盘后仍然存在。

ESET研究员Martin Smolár在周二写道："这些旧版中间件之所以危险，并不是因为发现了新的漏洞。真正的问题在于，不需要新的漏洞就能绕过UEFI安全启动。攻击者不需要复杂的利用技术，只需要一个仍然可信但未被撤销的旧版中间件二进制文件副本，以及对UEFI中间件工作原理的基本理解。这些就足以绕过如此关键的安全功能——UEFI安全启动。"

安全启动机制于2012年推出，旨在缓解启动后门程序（Bootkits）的威胁。没有安全启动机制，攻击者只需短暂的物理接触设备（即使设备关闭时）就能安装类似LoJax（2018年俄罗斯国家黑客使用）、MosaicRegressor（2020年发现）、CosmicStrand（2022年发现）和BlackLotus（2023年发现）的启动后门程序。其他一些野外发现的启动后门程序包括ESpecter、FinSpy和MoonBounce等。

虽然大多数启动后门恶意软件需要攻击者对目标设备有物理接触，但这种接触正是安全启动机制明确需要防范的威胁模型之一。

CERT汇编的11个中间件列表显示，其中一些被Linux发行商如Redhat、OpenSuse和Oracle使用。其他中间件属于第三方软件，如芬兰PC-Doctor的Matriculation Examination Board。其中许多中间件是在SBAT和MOK拒绝列表等保护机制存在之前构建的。其他中间件则包含其代码或授权的第二阶段二进制文件中累积的错误。

微软为Windows提供的数字签名UEFI引导程序是Windows设备上唯一信任锚点。在启动过程中，若要加载某个组件，其证书必须显式签名所有在启动期间执行的其他代码。

引导中间件的工作方式有所不同。它们是次要的信任锚点，由微软使用其另一张UEFI证书进行签名。随后，嵌入在引导中间件中的主板或软件制造商证书将授权所有后续加载的软件。

当发现引导中间件存在漏洞时，微软会将其撤销。在涉及11个引导中间件的案例中，微软未能及时执行撤销操作，部分案例甚至持续了十余年。在ESET向CERT和微软通报后，微软最终于6月的常规月度补丁更新中撤销了这些中间件。

执行的敌人是复杂性

微软尚未解释此次疏漏发生的原因和方式。一个可能的原因是Secure Boot机制的高度复杂性。Windows引导管理器和UEFI引导中间件均加载两个数据库。db数据库列出了所有允许的签名证书和Authenticode哈希值。dbx数据库包含不再受信任的证书和哈希值。要加载某个组件，必须通过db数据库授权且未在dbx数据库中被撤销。

由于启动过程中执行的Linux组件数量庞大，无法将每个组件都列入这些数据库，因为dbx数据库仅分配了32KB空间。因此微软采用了其他撤销方法，具体为SBAT（Secure Boot Advanced Targeting）和Secure Boot安全版本号（SVN）。

Smolár解释称："简而言之，dbx用于撤销二进制文件，而SBAT和微软的Secure Boot SVN用于撤销版本。" "当发现支持这些基于版本撤销机制的UEFI应用程序存在漏洞时，真正需要阻止的是所有包含漏洞版本的构建版本——通过版本号比通过长长的哈希列表更容易实现。"

UEFI加载器中的每个组件都携带元数据，这些元数据由与二进制文件本身认证证书相同的证书签名。该元数据会命名组件并分配一个生成号，每次发布新的安全补丁时该生成号会递增。

UEFI中的一个仅用于启动的变量会存储每个组件允许的最低生成号。该变量值由引导中间件而非固件强制执行。

引导中间件还会嵌入策略，使执行不完全依赖外部变量。这使得通过称为SbatLevel的机制引入新策略成为可能。

研究人员写道："每次启动时，引导中间件首先会将自己的SBAT元数据与策略进行验证——从而使过时的引导中间件能够拒绝自身——然后对加载的每个二进制文件执行相同测试，拒绝所有生成号低于策略要求最低值的文件。"

该过程的复杂性远不止于此。结果是，引导中间件同时嵌入了由供应商管理的证书和内置的引导中间件证书，这两个证书授权所有后续加载的引导程序和实用工具。希望获得更详细描述的读者可以参阅周二文章的这一部分。

此外，即使微软用于签署引导中间件的证书已于上月末过期，这也不足以撤销ESET识别出的那些引导中间件。

有缺陷的引导中间件画廊

被 ESET 识别出的 shim（补丁）授权了已知存在多种漏洞利用风险的次要组件。例如，Oracle shim 会为存在 CVE-2015-5381 漏洞的二进制文件签名。Smolár 表示，利用该漏洞所需的技术门槛较低。其他存在漏洞的 shim 无法支持保护机制，例如 MOK 拒绝列表执行和 SBAT 执行，这两种机制在相关 shim 发布后才生效。还有其他被识别出的 shim 本身代码中也存在漏洞。

为简洁起见，本周二报告中包含的许多其他细节在此文章中未予呈现。

令人不安的前景

如前所述，这些存在漏洞的 shim 可用于攻击 Windows 和 Linux 机器，尽管默认状态下可能无法攻击 Windows 11 Secured-core PC。任何已安装微软六月更新包的 Windows 用户已不再面临此漏洞风险。Linux 用户应检查 Linux Vendor Firmware Service 或咨询其发行商。可通过 uefi-dbx-audit 脚本查询撤销状态。

攻击者在过去十年中通过类似“按部就班的脚本”绕过安全启动机制的手段，显然无法证明微软与硬件厂商合作提出的机制具有可靠性。如前所述，此次事件的主要原因之一是其复杂性。

“这无疑是对整个安全启动模型的有力反驳，”固件安全专家、runZero 公司首席执行官兼创始人 HD Moore 在接受采访时表示。他批评的要点包括微软实际上成为整个 UEFI 平台的信任根，保护机制扩展性不足，以及即使顶级证书过期后组件仍能启动的问题。

Moore 补充道：“最终结果是大量未被公开（除微软外）的已签名内容绕过了安全启动机制——其中一些还可用于启动其他内容——这些内容既有常规安全漏洞，也存在其他错误，意味着它们几乎可以启动任何东西。”他指出：“整个生态系统存在严重缺陷，亟需重启。”

高级安全编辑

Dan Goodin 是 Ars Technica 的高级安全编辑，负责监督恶意软件、计算机间谍活动、僵尸网络、硬件黑客攻击、加密和密码方面的报道。在工作之余，他喜欢园艺、烹饪以及关注独立音乐场景。Dan 常驻旧金山，可通过 [此处](here) 在 Mastodon 和 [此处](on Bluesky) 在 Bluesky 跟踪他的动态。可通过 Signal 在 DanArs.82 联系他。

56 条评论