CVE-2025-3052漏洞分析：微软UEFI证书签名模块中的安全启动绕过

近期，Binarly研究团队披露了一个影响广泛UEFI设备的安全启动（Secure Boot）绕过漏洞，其核心是 CVE-2025-3052 (BRLY-2025-001)。该漏洞存在于一个由微软第三方UEFI证书签名的模块中，攻击者可借此在操作系统加载前运行未签名代码，从而有效绕过安全启动，破坏整个系统的信任链条。由于攻击者的代码在操作系统自身防御建立前就已执行，这为后续植入持久化恶意软件打开了大门。

这项发现源于在VirusTotal上公开的一个UEFI应用程序，它由微软的第三方UEFI证书签名。虽然该文件首次提交时间是2024年11月，但其签名数据显示签署于2022年10月，这意味着它可能已在生态系统中流通了更长时间。该应用程序是DT Research公司（一家加固移动设备制造商）产品的BIOS刷新工具。尽管最初为特定设备开发，但该模块能在任何信任主题为 “Microsoft Corporation UEFI CA 2011” 证书的设备上运行。这包括了绝大多数现代系统，因为同一证书也被广泛用于签署Linux引导加载程序shim，极大地扩展了此漏洞的潜在影响范围。

图1：使用微软 UEFI CA 2011 证书签名的易受攻击模块

漏洞的根源，再次指向了对NVRAM变量的不安全处理。这类问题在UEFI生态系统中屡见不鲜。Binarly通过其透明平台（Binarly Transparency Platform）执行专项分析，自动检测此类对NVRAM变量数据的不安全使用，并由此发现了CVE-2025-3052。

具体来说，已签名的应用程序会读取一个名为 IhisiParamBuffer 的NVRAM变量内容，并未经验证地直接将其用作多个内存写入操作的目标指针。这导致攻击者可以通过设置该变量为内存中的任意地址，从而获得任意内存写入的能力。

图2：签名的模块盲目信任来自 NVRAM 变量的指针进行内存写入

Binarly于2025年2月26日向CERT/CC报告了此发现。在与微软的沟通中，问题范围进一步扩大：它并非仅影响单一模块，而是涉及14个不同的模块。作为缓解措施，微软在2025年6月的补丁星期二更新中，向安全启动禁止列表 (dbx) 添加了14个新的哈希值。

安全启动与微软证书的作用回顾

要理解CVE-2025-3052的严重性，我们得先明确安全启动扮演的角色。安全启动是UEFI信任链的关键一环，负责在固件将控制权移交给操作系统之前，验证操作系统加载器的完整性和真实性。这能有效阻止攻击者用恶意启动程序替换合法的加载器。

UEFI应用程序由叶证书的私钥签名，该证书通过中间证书链连接到存储在 db（签名数据库）中的受信任根CA证书。验证过程依赖于 db（允许的签名/证书）和 dbx（已撤销或禁止的签名/证书）两个数据库。

默认情况下，大多数设备的 db 中包含以下可信证书：

1. Microsoft Windows Production PCA 2011 — 用于签署Windows引导加载程序。
2. Microsoft Corporation UEFI CA 2011 — 用于验证第三方引导加载程序和组件（包括Linux的shim）。
3. OEM自有证书 — 由硬件制造商控制。

而易受攻击的应用程序，正是由上述第二个被广泛信任的证书签署的。

图3：UEFI 安全启动签名和验证流程概要

漏洞模块的发现与分析

这项研究始于在VirusTotal上发现一个名为 Dtbios-efi64-71.22.efi 的UEFI模块。尽管首次提交在2024年11月，但其签署时间戳显示为2022年10月。通过分析文件名、Authenticode证书信息及二进制内部字符串，可以确认该模块由DT Research开发，其功能是一个BIOS更新工具。同时，漏洞涉及的NVRAM变量名称 IhisiParamBuffer 指向了Insyde（系微）作为相关的BIOS供应商。

图4：VirusTotal 上易受攻击模块的截图

CVE-2025-3052的发现与利用

Binarly透明平台自动检测到了此漏洞。生成的报告清晰指出了问题的根源：使用了源自NVRAM变量的不可信指针，并且平台的可达性分析确认，易受攻击的函数可以直接从模块入口点访问，这意味着它很可能被利用。

图5：由 Binarly 透明平台生成的报告

漏洞的伪代码逻辑清晰：易受攻击的函数读取NVRAM变量 IhisiParamBuffer 的值，并将其直接用作后续内存写入操作的目标地址，而写入的值是零。这为攻击者提供了向任意地址写入零的能力。

虽然看似只能写零，但这已构成一个强大的攻击原语。在概念验证（PoC）中，研究者选择覆盖一个名为 gSecurity2 的全局变量。该变量在EDK2实现中指向Security2架构协议，LoadImage 函数依靠它来强制执行安全启动策略。通过将其覆盖为零，即可有效禁用安全启动，从而允许执行任何未签名的UEFI模块。

一个有趣的前提是，IhisiParamBuffer 变量必须可由攻击者写入。在基于Insyde的设备上，该变量通常被锁定为只读。然而，所有其他信任微软UEFI CA 2011证书的设备均可能受此漏洞影响。这种情况凸显了UEFI供应链安全的复杂性：一个供应商的编码错误，最终可能影响整个生态系统中的其他厂商，而该供应商自己的设备却可能因为额外的保护机制而免受影响。

图7：利用 CVE-2025-3052 的 PoC 高层概述

攻击流程概述如下：

1. 特权攻击者从操作系统中将 IhisiParamBuffer 变量设置为目标内存地址（例如 gSecurity2 的地址）。
2. 攻击者在UEFI启动管理器中注册易受攻击的签名模块，并同时注册一个包含实际有效载荷的未签名模块。
3. 设备重启。
4. 固件执行易受攻击的模块，其任意写入能力覆盖 gSecurity2 并禁用安全启动。随后，第二个未签名模块被成功加载和执行，攻击者获得任意代码执行权限。

结论与缓解措施

发现漏洞后，Binarly立即启动了负责任的披露流程。微软确认了共14个受影响的模块，并在2025年6月的 dbx 更新中将它们全部列入禁止名单。下表列出了这14个模块及其对应的Authenticode SHA256哈希：

最直接的缓解措施是确保系统及时应用最新的 dbx 更新。过时或不一致的 dbx 数据库会持续让设备暴露在已知漏洞的攻击风险之下。

安全启动绕过漏洞在UEFI生态系统中持续出现，这提醒我们固件层安全的重要性。对于企业安全团队和高级用户而言，保持对这类底层威胁的关注，并利用专业的安全分析平台或工具进行资产盘点与漏洞检测，是构建纵深防御体系不可或缺的一环。