一项由微软发明、旨在保护Windows及Linux设备免受固件感染的行业标准，在其14年的存在历史中，有长达13年的时间都可以轻易被绕过。这一发现来自安全公司ESET的研究人员，他们识别出11个固件镜像，其中至少一个来自2013年，这些镜像早已被证实存在缺陷，但微软却始终未撤销对其的签名。
这些镜像被称为"shim"，最初是为了将安全启动（Secure Boot）扩展至Linux设备和实用软件而设计。利用一种简单到连初级黑客都能掌握的技术，这些被遗忘已久的旧shim文件可以完全绕过安全启动保护。该保护机制内嵌于主板的UEFI（统一可扩展固件接口）之中。此次疏漏的根源在于，微软作为shim签名的主管方，在发现相关漏洞后，未能及时撤销这些公开可用的镜像。
这一威胁同时波及Windows和Linux用户，因为shim可以安装在运行这两种操作系统的设备上。一旦攻击者成功植入，便可颠覆强制性的数字签名固件验证链，进而安装恶意固件。这类固件会在系统启动早期阶段加载，即便重新安装操作系统或更换硬盘，恶意代码依然会持续存在。
ESET研究员马丁·斯莫拉尔周二撰文指出："这些旧版shim之所以危险，并不在于存在什么新漏洞，而恰恰在于绕过UEFI安全启动根本不需要任何新漏洞。攻击者无需复杂的利用技术，只需一份旧版但仍受信任且未被撤销的shim二进制文件，加上对UEFI shim基本工作原理的了解，就足以绕过安全启动这一关键安全机制。"
安全启动于2012年正式推出，旨在防范"bootkit"——即此类恶意固件的威胁。若缺少安全启动保护，攻击者即使对设备仅有短暂的物理接触（甚至在设备关机状态下），也能安装类似以下恶意程序的bootkit：2018年被俄罗斯国家黑客使用的LoJax、2020年发现的MosaicRegressor、2022年的CosmicStrand，以及2023年的BlackLotus。此外，还有ESpecter、FinSpy和MoonBounce等多种在野bootkit被持续追踪。
大多数bootkit恶意软件需要攻击者对目标设备拥有物理访问权限，而安全启动明确将此作为需要防护的威胁场景之一。
CERT整理的11个shim完整列表显示，部分shim曾被Red Hat、OpenSUSE和Oracle等Linux发行商使用，另一些则属于PC-Doctor Finland芬兰高考委员会等第三方软件。许多shim在SBAT和MOK拒绝列表等保护机制出现之前便已构建，其余shim则在其代码或所授权的第二阶段二进制文件中存在累积性漏洞。
微软经过数字签名的UEFI引导加载程序是Windows设备上唯一的信任锚点，启动过程中加载的所有组件，都必须经由该证书对启动期间执行的全部代码进行明确签名认证。
Shim的工作方式则有所不同。它是一种次级信任锚点，由微软使用另一个UEFI证书进行签名，此后，嵌入shim中的主板或软件厂商证书将对后续加载的所有软件进行授权。
当shim中发现漏洞时，微软通常会撤销相应签名。然而对于这11个shim，微软在部分案例中长达十余年未予撤销。在ESET将此问题反映给CERT和微软后，该公司才于今年6月的例行月度补丁更新中完成了撤销操作。
目前，微软尚未就此次疏漏的经过和原因作出说明。一种可能的解释是安全启动机制本身的高度复杂性。Windows启动管理器与UEFI shim均会加载两个数据库：db数据库列出所有受信任的签名证书和Authenticode哈希值，dbx则包含不再受信任的证书和哈希值。组件若要成功加载，必须经过db的授权，且不得出现在dbx的撤销列表中。
Q&A
Q1：什么是UEFI安全启动（Secure Boot），它的作用是什么？
A：UEFI安全启动是微软于2012年推出的一项安全机制，内嵌于设备主板的UEFI固件中，旨在防止恶意固件（bootkit）在系统启动阶段被加载。它通过强制验证数字签名的方式，确保启动过程中执行的每一段代码都经过授权，从而阻止攻击者在操作系统启动前植入恶意程序。即便重装系统或更换硬盘，bootkit仍可持续存在，因此安全启动是防范此类威胁的关键防线。
Q2：ESET发现的安全启动漏洞具体是什么问题？
A：ESET研究人员发现，有11个名为"shim"的固件镜像虽已被证实存在安全缺陷，但微软长达十余年未对其进行签名撤销。由于这些旧版shim仍处于受信任状态，攻击者无需利用任何新漏洞，只需获取一份旧版shim文件，即可完全绕过UEFI安全启动保护，进而在设备上安装持久性恶意固件，且该威胁同时影响Windows和Linux用户。
Q3：微软是如何处理这次安全启动漏洞的？
A：在ESET将问题上报给CERT和微软后，微软于2024年6月的例行月度补丁更新中，正式撤销了这11个存在缺陷的shim镜像签名。然而微软至今尚未公开解释此次长期疏漏的具体原因。研究人员推测，安全启动机制本身的复杂性，尤其是db与dbx双数据库的管理机制，可能是导致撤销工作长期未能落实的原因之一。
