微软的Secure Boot已被攻破十年，至今才被发现

# 微软安全启动存在十年漏洞，至今才被发现 来源：https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/ 安全启动需要重启 微软未撤销的旧版“垫片”（shims）让安全启动绕过变得轻而易举。 手指即将按下电源键。硬件设备概念图。图片来源：Getty Images 微软为保护 Windows 及后来 Linux 设备免受固件感染而发明的一项行业标准，在其 14 年的存在历史中，有 13 年可被轻易绕过。这一发现由安全公司 ESET 的研究人员做出，他们在识别出 11 个固件映像后得出结论——这些映像（至少有一个源自 2013 年）已知存在缺陷，却仍被微软签署。 这些映像被称为 shims（垫片），最初是为了将安全启动扩展到 Linux 设备和实用软件而发明的。通过一种简单到新手黑客都能执行的技术，这些被遗忘的旧版 shims 可以被用来完全规避嵌入在设备主板 UEFI（统一可扩展固件接口）中的保护机制。这一失误源于负责签署 shims 的微软未能及时撤销这些已知存在漏洞的公开映像。 ## 威胁波及 Windows 和 Linux 用户 该威胁同时影响 Windows 和 Linux 用户，因为 shim 可以安装在运行这两种操作系统的设备上。攻击者可以借此破坏强制性的数字签名固件链，安装恶意固件，该固件在启动过程早期加载，并且在操作系统重装或硬盘更换后依然存在。 “这些旧版 shim 的危险性并不在于存在新漏洞，”ESET 研究员 Martin Smolár 周二写道（https://www.welivesecurity.com/en/eset-research/forgotten-uefi-shims-undermining-secure-boot/），“而是在于绕过 UEFI 安全启动根本不需要新漏洞。攻击者无需复杂的利用原语——只需一份旧的、仍被信任但未被撤销的 shim 二进制文件，以及对 UEFI shim 工作原理的基本了解。这就足以绕过像 UEFI 安全启动这样至关重要的安全功能。” 安全启动于 2012 年引入，旨在遏制此类恶意固件（即 bootkit）的威胁。没有安全启动，短暂物理接触设备的攻击者（即使设备已关机）也可以安装类似于 2018 年俄罗斯国家黑客使用的 LoJax（https://arstechnica.com/information-technology/2018/10/first-uefi-malware-discovered-in-wild-is-laptop-security-software-hijacked-by-russians/）、2020 年发现的 MosaicRegressor（https://arstechnica.com/information-technology/2020/10/custom-made-uefi-bootkit-found-lurking-in-the-wild/）、2022 年的 CosmicStrand（https://arstechnica.com/information-technology/2022/07/researchers-unpack-unkillable-uefi-rootkit-that-survives-os-reinstalls/）以及 2023 年的 BlackLotus（https://arstechnica.com/information-technology/2023/03/unkillable-uefi-malware-bypassing-secure-boot-enabled-by-unpatchable-windows-flaw/）等 bootkit。此外，还有一些在野 bootkit 被追踪为 ESpecter、FinSpy 和 MoonBounce（https://securelist.com/moonbounce-the-dark-side-of-uefi-firmware/105468/）。 大多数（并非全部）bootkit 恶意软件需要攻击者物理接触目标设备。这种接触正是安全启动明确要求抵御的威胁模型之一。 CERT 编制的全部 11 个 shim 列表（https://kb.cert.org/vuls/id/616257）显示，其中一些被 Redhat、OpenSuse 和 Oracle 等 Linux 发行商使用。其他则属于第三方软件，例如 PC-Doctor Finland 的 Matriculation Examination Board。许多 shim 构建于某些保护机制（包括 SBAT 和 MOK 拒绝列表）出现之前。其他 shim 则在其代码或所授权的第二阶段二进制文件中存在积累的 bug。 微软数字签名的 Windows UEFI 启动加载器是 Windows 机器上唯一的信任锚点。要使组件在启动过程中加载，该证书必须明确签署启动期间执行的所有其他代码。 Shim 的工作方式不同。它们是二级信任锚点，由微软使用其另一个 UEFI 证书签署。随后，嵌入在 shim 中的主板或软件制造商证书授权后续加载的所有软件。 当在 shim 中发现漏洞时，微软会将其撤销。对于这 11 个 shim，微软未能做到这一点，某些情况下甚至超过十年。在 ESET 将其告知 CERT 和微软后，该公司终于在 6 月的常规月度补丁中撤销了这些 shim。 ## 复杂性是执行的敌人 微软尚未解释这一疏忽如何或为何发生。一个可能的原因是安全启动工作方式的高度复杂性。Windows Boot Manager 和 UEFI shim 都加载两个数据库。db 数据库列出所有允许的签名证书和 Authenticode 哈希值。dbx 包含不再受信任的证书和哈希值。要加载某个组件，它必须通过 db 授权，并且不在 dbx 中被撤销。 鉴于启动过程中执行的大量 Linux 组件，将这些组件逐一列在数据库中是行不通的，因为 dbx 仅被分配了 32KB 的空间。因此，微软求助于其他撤销方法，特别是 SBAT（安全启动高级定位）和安全启动安全版本号（SVN）。 “简而言之，dbx 撤销的是二进制文件，而 SBAT 和微软的安全启动 SVN 撤销的是版本，”Smolár 解释道。“当在支持这些基于版本的撤销机制的 UEFI 应用程序中发现漏洞时，真正需要阻止的是所有构建版本（包括存在缺陷的版本）——这可以通过版本号比通过一长串哈希值更容易捕获。” UEFI 加载器中的每个组件都携带元数据，这些元数据由签署该二进制文件本身的同一证书签署。此元数据命名该组件并分配一个生成号，每次发布新安全修复时，该生成号都会递增。 UEFI 中的一个仅启动变量存储每个组件允许的最低生成号。该变量号由 shim 而非固件强制执行。 Shim 还嵌入了策略，因此执行不完全依赖外部变量。这允许通过称为 SbatLevel 的机制纳入新策略。 “每次启动时，shim 首先根据策略验证自身的 SBAT 元数据——因此过时的 shim 可以被要求拒绝自身——然后对加载的每个二进制文件应用相同的测试，拒绝任何生成号低于策略要求最低值的组件，”研究人员写道。 该过程的复杂性并不止于此。其结果是，shim 嵌入了供应商管理的和内置的 shim 证书，这些证书授权随后加载的所有引导加载程序和实用程序。希望获得更详细描述的读者可以参考周二文章中（https://www.welivesecurity.com/en/eset-research/forgotten-uefi-shims-undermining-secure-boot/#Secure%20Boot%20Advanced%20Targeting%20(SBAT)）的此部分内容。 进一步复杂化该过程的是，即使签署 shim 的微软证书过期——这发生在上个月底（https://arstechnica.com/security/2026/06/windows-and-linux-users-the-deadline-to-update-secure-boot-keys-is-near/）——也不足以撤销 ESET 所识别的那些 shim。 ## 缺陷 shim 的“恶棍画廊” ESET 识别的 shim 授权的次级组件已知易受各种漏洞利用。例如，Oracle shim 签署了一个易受 CVE-2015-5381（https://nvd.nist.gov/vuln/detail/CVE-2015-5281）攻击的二进制文件。Smolár 表示，利用该漏洞所需的技能水平很低。其他易受攻击的 shim 未能支持某些保护机制，例如 MOK 拒绝列表执行和 SBAT 执行，这两者都是在受影响的 shim 发布后才生效的。还有一些被识别的 shim 在其自身代码中包含漏洞。 为简洁起见，本文省略了周二报告中包含的许多其他详细信息。 ## 令人不安的前景 如前所述，这些易受攻击的 shim 可用于攻击 Windows 和 Linux 机器，但很可能不适用于默认状态下的 Windows 11 安全核心 PC。任何安装了微软 6 月更新批次的 Windows 用户都不再易受攻击。Linux 用户应检查 Linux 供应商固件服务（https://fwupd.org/）或咨询其发行商。可使用 uefi-dbx-audit（https://github.com/sei-vsarvepalli/uefi-dbx-audit/）脚本查看撤销状态。 攻击者通过近乎数字编号的黑客脚本在十多年间一直能够绕过安全启动，这种可能性并没有对微软与硬件制造商合作提出的这一机制构成多少背书。如前所述，导致这一灾难的关键因素是其复杂性。 “这是对整个安全启动模式的坚实驳斥，”固件安全专家、runZero 首席执行官兼创始人、长期批评安全启动的 HD Moore 在接受采访时表示。他的抱怨包括微软实际上是整个 UEFI 平台的信任根，该保护机制无法充分扩展，以及即使顶级证书过期，组件仍可启动。 “最终结果是大量（除微软外无人知晓的）已签名内容绕过了安全启动——其中一些还可以用来引导其他内容——而且这些内容本身存在正常的 security bug 和其他错误，意味着它们几乎可以用来引导任何东西，”Moore 补充道。“整个生态系统有些破碎，需要重启。” Dan Goodin 照片（https://arstechnica.com/author/dan-goodin/） Dan Goodin 是 Ars Technica 的高级安全编辑，负责报道恶意软件、计算机间谍、僵尸网络、硬件黑客、加密和密码等内容。业余时间，他喜欢园艺、烹饪和关注独立音乐场景。Dan 现居旧金山。可在 Mastodon 上关注他：https://infosec.exchange/@dangoodin，在 Bluesky 上关注他：https://bsky.app/profile/dangoodin.bsky.social。可通过 Signal 联系他：DanArs.82。 43 条评论（https://arstechnica.com/security/2026/07/microsoft-secure-boot-has-been-broken-for-most-of-its-existence/#comments） 1. 热门阅读中的第一个故事配图：SpaceX 正在为本周晚些时候的星舰第 13 次试飞做准备（https://arstechnica.com/space/2026/07/spacex-is-gearing-up-for-starships-13th-test-flight-later-this-week/）