*信任链条上的又一道裂痕：揭秘另一个安全启动绕过漏洞 (CVE-2025-3052)

在本篇文章中，Binarly 研究团队详细记录了可能影响大多数支持 UEFI 的设备的安全启动绕过漏洞。此发现的核心是 CVE-2025-3052 (BRLY-2025-001)，一个存在于微软第三方 UEFI 证书签名模块中的内存破坏漏洞。攻击者可利用此漏洞在启动过程中运行未签名代码，从而有效绕过安全启动，破坏系统的信任链。由于攻击者的代码在操作系统加载之前就已执行，这为攻击者安装启动包和破坏操作系统级的安全防御打开了大门。

此次发现的背后源自我们在 VirusTotal 上发现的一个 UEFI 应用程序，该程序由微软的第三方 UEFI 证书签名。该应用程序自 2024 年 11 月首次提交以来一直公开可见。然而，签名数据表明它实际上是在 2022 年 10 月签署的，这意味着它可能已流通了更长时间。

该应用程序是 DT Research（一家专注于加固移动设备公司）销售的设备的 BIOS 刷新工具。虽然该模块最初仅为 DT Research 设备开发，但它可以在任何信任主题为 “Microsoft Corporation UEFI CA 2011” 证书的设备上运行。这包括了绝大多数系统，因为相同的证书被广泛用于签署 Linux 引导加载程序 shim，这极大地增加了此漏洞的潜在影响。

图1. 由微软 UEFI CA 2011 证书签名的易受攻击模块

此漏洞的根本原因，再次在于对 NVRAM 变量的不安全处理。涉及 NVRAM 变量的问题一直是 UEFI 生态系统中一个持续存在的问题，仅 Binarly 一家在过去几年中就负责任地披露了数百个相关漏洞。由于这些错误如此广泛且影响深远，我们的 Binarly Transparency Platform（透明平台）执行了多项分析来检测此类错误。其中一项检查专门查找对从 NVRAM 变量读取数据的任何不安全使用，正是这项分析自动发现了 CVE-2025-3052。

如下方图像所示，已签名的应用程序读取 IhisiParamBuffer 变量的内容，并直接将其用作多个内存写入操作的指针，而未对其值执行任何验证或健全性检查。这使得攻击者可以将 IhisiParamBuffer 变量设置为内存中的任意地址，从而有效地赋予他们任意内存写入的能力。

图2. 签名的模块盲目信任来自 NVRAM 变量的指针进行内存写入 (CVE-2025-3052)

我们于 2025 年 2 月 26 日向 CERT/CC 报告了此发现。在与微软披露期间，情况变得明朗：此问题不仅限于单个模块，实际上影响了 14 个不同的模块。因此，为了解决 CVE-2025-3052，微软向安全启动禁止列表 (dbx) 中添加了 14 个新的哈希值作为缓解措施，该更新作为 2025 年 6 月补丁星期二的一部分发布。

安全启动和微软证书

在深入探讨 CVE-2025-3052 的细节之前，让我们回顾一下安全启动是什么以及它解决了哪些安全问题。首先，安全启动在 UEFI 构建的信任链中扮演着至关重要的角色。它可以被看作是连接系统固件和操作系统之间的桥梁，将信任从一个端点传递到另一个端点。在平台初始化完毕的 DXE 阶段结束时，固件准备启动操作系统。在安全启动启用的情况下，固件会在移交控制权之前对操作系统加载器进行加密验证其完整性和真实性。此检查阻止攻击者用恶意组件（如启动包）替换合法的操作系统加载器。没有安全启动，攻击者可以轻易地获得早期执行权限，在操作系统甚至有机会安装其防御措施之前就破坏其防御。

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

UEFI 应用程序由签名证书（图中叶证书）的私钥部分签名，该证书通过一个或多个中间证书链接到来自 db 的受信任的根 CA 证书。例如，这就是由微软签名应用程序的情况，其中主题为 “Microsoft Corporation UEFI CA 2011” 的证书的私钥对叶证书进行签名，后者的私钥又用于签署 UEFI 应用程序的 Authenticode 哈希。

验证过程则基于两个签名数据库：db 和 dbx。db 包含可信的 Authenticode 哈希和根证书列表：

• 如果 db 中的任何 Authenticode 哈希与应用程序的 Authenticode 哈希匹配，则允许运行该应用程序。
• 如果 db 中的任何根证书成功验证了应用程序的证书链，则允许运行该应用程序。

而 dbx 则包含不受信任或已撤销的 Authenticode 哈希和证书。

根据应用程序是否已签名，固件根据其 Authenticode 哈希或 CA 证书是否存在于 db 中且不在 dbx 中来允许执行。默认情况下，大多数设备出厂时至少在 db 中包含以下可信证书：

1. Microsoft Windows Production PCA 2011 — 用于签署 Windows 引导加载程序。
2. Microsoft Corporation UEFI CA 2011 — 用于验证第三方引导加载程序和组件。
3. OEM 自有证书 — 特定于硬件制造商，通常用于与硬件相关或维护的模块。

第二个证书用于签署易受攻击的应用程序。如前所述，此证书被广泛信任并存在于 db 中，因为它被用于签署诸如 Linux 的 shim 等组件，后者是负责启动 Linux 系统的 EFI 应用程序。

起始：模块发现和侦察

这项研究始于在 VirusTotal 上发现易受攻击的 UEFI 模块。VirusTotal 上的首次提交是在 2024 年 11 月，但签署时间可以追溯到 2022 年 10 月，这意味着该模块可能存在了更长时间。原始提交的文件名是 Dtbios-efi64-71.22.efi。该文件名，结合 Authenticode 证书中的详细信息以及二进制文件本身内部的字符串，使我们得出结论，该模块由 “DT Research” 开发。

此外，易受攻击的 NVRAM 变量名称立即指向 Insyde（系微）作为相关的独立 BIOS 供应商。这个相同的变量之前已经是我们报告的两个漏洞的核心：BRLY-2022-023 和 BRLY-2023-005。

经过一番逆向分析，我们还得出结论：该模块是一款 BIOS 更新工具，因为它从文件中读取 BIOS 镜像并尝试将其刷写到设备的 ROM 中。

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

中断：发现并利用 CVE-2025-3052

我们的 Binarly Transparency Platform 可以自动检测广泛的 UEFI 相关漏洞，包括涉及 NVRAM 变量处理的问题。因此，发现 CVE-2025-3052 背后的漏洞就像将受影响的模块上传到我们的平台一样简单。

生成的报告（如下图）立即揭示了此发现的影响：漏洞的根本原因是对源自 NVRAM 变量的不可信指针的使用。此外，我们的专利可达性指标证实，易受攻击的函数可以直接从模块的入口点访问，因此很可能可以被利用。

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

下一张图片显示的伪代码，由我们的平台作为问题证据生成，实现了对漏洞的快速有效分类。该伪代码是使用 Binarly 的程序分析框架（提供全面的静态分析技术）生成的。

易受攻击的函数读取 NVRAM 变量 IhisiParamBuffer 的值，并将其存储在地址为 0xf7a0 的全局变量中。随后，此全局变量的值加上 0x18 被用作内存写入操作的目标地址，将其设为零。后续的写入也受攻击者控制，因为 var2 指向相同的 NVRAM 变量。

图6. 作为发现证据生成的伪代码。

虽然这种写入能力有限制，因为它只允许将零或几个常量写入任意地址，但它提供了一个强大的原语，可以以各种创新的方式被利用。对于我们的概念验证 (PoC)，我们选择覆盖全局变量 gSecurity2（此变量是 EDK2 实现中管理安全策略的关键结构）。该变量保存指向 Security2 架构协议的指针，LoadImage 函数使用它来强制执行安全启动。通过将其设为零，我们有效地禁用了安全启动，允许执行任何未签名的 UEFI 模块。

此漏洞的一个先决条件是 IhisiParamBuffer 变量必须可写。在基于 Insyde 的设备上，此变量通常被锁定且为只读。因此，除非存在另一个漏洞（例如 BRLY-2023-005，该漏洞允许设置任意变量，即使被锁定），否则基于 Insyde 的设备不易受此攻击。

然而，所有其他设备仍然易受攻击。仔细想想，这种情况相当独特，并且再次突显了围绕 UEFI 供应链安全的复杂性，其中一个供应商的错误可以影响整个生态系统，除了该供应商本身！

下图提供了利用 CVE-2025-3052 进行攻击的高层概述。特权攻击者可以从操作系统设置 IhisiParamBuffer 变量（步骤 1），并在 UEFI 启动管理器中注册易受攻击的模块，或用恶意模块替换现有的操作系统加载器。

此外，攻击者注册第二个包含他们打算执行的实际有效载荷的未签名模块（步骤 2）。受害者设备重启后（步骤 3），固件进入启动设备选择阶段，并执行易受攻击的模块。其任意写入能力使攻击者能够覆盖 gSecurity2，从而有效禁用安全启动。安全启动被禁用后，第二个未签名模块随后被固件加载和执行，从而在 DXE 阶段结束时授予攻击者任意代码执行权限（步骤 4）。

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

基于先前的描述，我们录制了一个演示视频，展示了此 PoC 的不同阶段。一个重要的方面是，PoC 对操作系统是透明的：如视频结尾（1分07秒处）所示，从操作系统的角度来看安全启动似乎仍然启用，即使它已经被有效地绕过。

结论：CVE-2025-3052 的披露与修复

发现此漏洞后，我们于 2025 年 2 月 26 日向 CERT/CC 提交了一份案件，以通知受影响方并帮助为受影响的 Binarly 客户提供修复和检测。

在分类过程中，微软确定该问题不仅影响最初认为的单一模块，而且实际上影响了 14 个不同的模块。因此，在 2025 年 6 月补丁星期二发布的最新 dbx 更新中包含了 14 个新的哈希值。

关于修复，我们建议受影响的用户尽快更新 dbx。在我们之前的研究博客“从信任到麻烦：破损 DBX 的供应链影响”中，我们详细描述了过时且不一致的 dbx 的潜在影响。

检测 CVE-2025-3052

安全启动绕过问题在 UEFI 生态系统中持续存在，每年都会出现几次新的漏洞。例如，在 2025 年 1 月，ESET 研究人员披露了另一个安全启动漏洞（CVE-2024-7344）的细节。此外，继今年早些时候我们发现的 dbx 中的不一致现象及其供应链影响之后，我们决定在产品中专门针对安全启动安全实施一个新功能。这一新增功能确保 Binarly 透明平台的用户能够及时收到关于影响安全启动的任何问题的精确发现，以便他们可以快速修复。

以下是 Binarly 透明平台检测和报告此安全启动绕过问题的演示。

Binarly 深度漏洞分析技术自动将 CVE-2025-3052 检测为先前未知的漏洞。

Binarly Mitigate 技术主动检测 DB/DBX 数据库中的已签名易受攻击模块，以突显潜在的高影响风险。（演示内容略）