微软牵头搞了一个行业标准，本意是给Windows和后来的Linux设备戴上一顶“固件防护盔甲”——UEFI安全启动。但尴尬的是，这顶盔甲在它存在的大约14年中，有13年都能被轻易掀开。这个发现可不是什么网络传闻，而是来自安全公司ESET的研究人员。他们在调查中找到了11个有缺陷的“垫片”固件映像，最早的那个甚至可以追溯到2013年。这些明知有漏洞的映像，竟然还一直被微软本人签着名，处于可用的状态。

这里说的“垫片”，是一个专门设计用来把安全启动扩展到Linux设备和配套软件上的组件。问题出在哪里？简单到连新手黑客都能上手的技术，就能利用这些被遗忘的旧垫片，彻底绕过嵌入在主板中的UEFI保护。究其原因，是微软在负责垫片签名的流程中间出现了失误——当一个垫片被发现存在漏洞后，它没能及时从公共可用列表中撤销。

威胁延伸至 Windows 和 Linux 用户

这个威胁并不是Windows或Linux用户某一方的专属麻烦，因为垫片可以安装在运行这两种操作系统的设备上。一旦被利用，攻击者就能破坏强制数字签名的固件链。结果是，他们可以安装恶意固件，这种恶意软件在系统启动的早期阶段就完成加载，哪怕你之后重装操作系统、甚至换掉硬盘，它依然能顽固地驻留在那里。

ESET的研究员Martin Smolár在一篇报告里写得很直白：“让这些旧垫片变得危险的，并不是什么新发现的漏洞。”他的原话是：“绕过UEFI安全启动根本不需要什么新漏洞。攻击者不需要复杂的利用手段，只需要一份旧版本、仍然被信任但没有被撤销的垫片二进制文件，再加上对UEFI垫片工作原理的基本了解。就这些，就足以绕过像UEFI安全启动这样一个基础的安全功能。”

安全启动是在2012年推出的，核心目标就是削弱Bootkit（对这类启动阶段恶意固件的统称）的威胁。如果没有它，攻击者只要对设备有短时间的物理访问——哪怕设备是关机状态——就能安装上像俄罗斯国家黑客在2018年用的LoJax、2020年发现的MosaicRegressor、2022年冒头的CosmicStrand，以及2023年出现的BlackLotus这类启动工具包。市场上还有一些以ESpecter、FinSpy、MoonBounce等名字被追踪的Bootkit变种。

需要说明的是，大多数（并非全部）Bootkit恶意软件都要求攻击者能接触到目标设备的物理接口。而这类物理接近的风险，恰恰是安全启动设计之初就要防范的主要威胁场景之一。

根据CERT整理出来的名单，这11个有问题的垫片，有些已经被Redhat、OpenSuse和Oracle这些Linux发行商集成使用了。还有些则属于第三方软件的一部分，比如芬兰PC-Doctor的考试系统。其中很多垫片建立的时间点，是在SBAT（安全启动高级目标）和MOK拒绝名单这类更完善的保护措施出现之前。另外一些垫片，要么自身的代码里有漏洞，要么它们授权加载的第二阶段二进制文件存在缺陷。

在Windows系统中，数字签名的UEFI引导加载程序是唯一被微软认可的信任锚。任何在启动过程中加载的组件，都必须有证书来显式签署它之后要执行的所有代码。

但垫片的工作方式有所不同。它本身是一个“次级”信任锚，由微软用自己另一套UEFI证书签了名。然后，垫片内部嵌入的、属于主板或软件制造商的证书，再来授权后续所有软件的加载。

按道理，垫片里发现漏洞后，微软会把它撤销。但对于这11个垫片，微软做到了“发现有漏洞”这一步，却没做到“撤销”。有的一拖就是十多年。直到ESET把这个问题捅给了CERT和微软，微软才在6月份的常规月度补丁中把这些垫片撤销掉。

复杂性是执行的敌人

微软没有公开解释这个失误是怎么发生的、为什么发生。一个可能的原因，是安全启动的工作机制确实复杂得让人头疼。Windows启动管理器和UEFI垫片都会加载两个数据库：一个是db数据库，列出所有被允许的签名证书和认证哈希值；另一个是dbx数据库，存放那些不再被信任的证书和哈希值。一个组件要能被成功加载，它必须通过db的授权，同时不能在dbx里被撤销。

但是问题来了：Linux在启动过程中需要加载的组件数量庞大，根本不可能把这些组件逐一列在db和dbx数据库中——因为dbx本身只有32KB的存储空间。所以微软采取了其他的撤销方法，尤其是SBAT和安全启动安全版本号（SVN）。

Smolár解释得很清楚：“简而言之，dbx是撤销具体的二进制文件，而SBAT和微软的安全启动SVN是撤销版本。”他接着说：“当在一个支持基于版本撤销机制的UEFI应用程序中发现漏洞时，真正需要排除的是每一个构建（包括有问题的那个）。通过版本号抓漏洞，比通过列表一长串哈希值要容易得多。”

UEFI加载器中的每个组件，都携带了由验证该二进制文件的同一证书签名的元数据。这个元数据会给组件命名，并分配一个代号，每次发布新的安全修复程序时，这个代号会递增。

UEFI里有个“仅引导变量”，专门存储每个组件允许的最小可接受代号。值得注意的是，这个变量号是由垫片本身来强制执行的，而不是靠固件本身。

垫片自己还嵌入了策略，所以它的执行不完全是依赖外部变量。这允许通过一个叫做“SbatLevel”的机制来引进新策略。

研究报告里写道：“每次启动时，垫片会先根据策略验证自己的SBAT元数据。这样一来，过时的垫片会自己拒绝自己。然后，它对它加载的每一个二进制文件都应用相同的测试，拒绝任何代数低于策略要求的最小值的组件。”

这个过程还没完。最终的情况是，垫片里嵌入了由供应商管理的内置证书，这个证书授权了后续加载的所有引导加载程序和实用程序。想了解更详细内容的读者，可以翻阅周二发布的那篇报告的相关章节。

让这个流程变得更复杂的是，即使上个月末，用来签署垫片的微软证书到期了，也还是不足以撤销ESET识别出来的那批有问题的垫片。

盗贼的有缺陷垫片画廊

ESET识别的这些垫片，授权了已知易受各种攻击的辅助组件。举个例子，Oracle的垫片签署了一个容易受CVE-2015-5381攻击的二进制文件。Smolár说，利用这个漏洞所需要的技术门槛非常低。另一些易受攻击的垫片，则干脆不支持像MOK拒绝列表强制执行和SBAT强制执行这类保护措施——而这些保护措施，恰恰是在这些有问题的垫片发布之后才生效的。当然，还有其他垫片自身的代码里就藏着漏洞。

为了节省篇幅，这篇文章就不把周二报告中那些更详细的细节都列出来了。

令人不安的前景

就像前面说的，这些有漏洞的垫片在Windows和Linux电脑上都能被利用——当然，默认状态下，Windows 11安全核心PC可能不在此列。任何安装了微软6月更新批次的Windows用户，现在应该已经不再受到这个威胁了。至于Linux用户，最好是检查一下Linux供应商的固件服务，或者直接咨询设备经销商。使用ufi-dbx-audit脚本可以获取当前的撤销状态。

十多年来，攻击者一直有办法通过现成的黑客脚本绕过安全启动。但这并不意味着我们要认可微软和硬件制造商当年合作推出的这个机制。前面反复提到的一个关键因素就是：它太复杂了。

“这简直是对整个安全启动模型的一次严厉谴责，”runZero的首席执行官兼创始人、长期批评安全启动的固件安全专家HD Moore在接受采访时这么说。他的抱怨包括：微软是整个UEFI平台事实上的信任根，保护措施无法充分扩展，以及即使在顶级证书过期后，组件依然可以启动。

“最终结果就是：有大量除了微软之外没人知道的、签了名的东西，可以绕过安全启动——其中一部分可以用来启动其他东西——而且它们都存在正常的安全漏洞或其他错误，意味着它们可以用来启动几乎任何东西。”Moore还补充道：“整个生态系统有点破损了，需要重启。”