CVE-2025-3052 — 已更新!
关于 CVE-2025-3052 的研究，这是一个 Insyde 固件漏洞，暴露了一个能够修改安全关键指针的任意写入原语。
🐞 CVE-2025-3052：IhisiParamBuffer 内存破坏
本仓库集中整理了与 CVE-2025-3052 相关的研究资料。该漏洞是一个存在于使用微软第三方证书签名的 UEFI 模块中的内存破坏漏洞，攻击者可借此破坏安全关键的固件结构、使 Secure Boot 强制机制失效，并在操作系统加载之前执行任意未签名代码。仓库内容包括对根本原因和利用技术的技术分析、真实世界与教学用的易受攻击二进制文件，以及辅助文档，旨在帮助研究人员理解、复现并实验此类漏洞。
📑 目录
🧠 原始发现与官方参考
CVE-2025-3052 最初由 Binarly 研究团队发现并负责任地披露。官方及社区参考：
- Binarly 研究博客（2025 年 6 月 10 日）
- 社区参考合集
🐜 易受攻击的二进制文件
本仓库包含两个易受攻击的二进制文件，分别对应不同的研究和学习目标。
🧨 真实世界易受攻击二进制文件
该二进制文件代表了该漏洞在真实环境中的存在形态。
- 受 CVE-2025-3052 影响的原始易受攻击 UEFI 应用程序。
- 用于真实世界分析和逆向工程。
- 使用微软第三方 UEFI 证书签名。
- 从公开恶意软件仓库中提取：
🎓 教学用易受攻击二进制文件
- 一个简化教学用 UEFI 应用程序的完整可编译源代码。
- 复现了与真实世界二进制文件相同的漏洞前提。
- 旨在帮助初学者：
- 逐步过渡到分析原始二进制文件。
- 在早期阶段避免繁重的逆向工程。
- 理解漏洞机制。
🧪 漏洞概述（分析、利用、PoC）
CVE-2025-3052 是一个影响 UEFI 系统的 Secure Boot 绕过漏洞，其成因是已签名 UEFI 应用程序中对从 NVRAM 变量读取的数据处理不当。该漏洞允许攻击者在启动过程中破坏安全关键的固件结构，从而有效破坏 UEFI 信任链，并在操作系统加载之前执行未签名代码。
使该漏洞影响尤为严重的，不仅是漏洞本身的性质——一种内存破坏原语——还在于其所处的环境：一个使用微软第三方 UEFI 证书签名的 UEFI 模块，而该证书在绝大多数现代系统上默认受信任。因此，利用行为发生在平台最早且权限最高的执行阶段之一，早于操作系统级安全控制。
🔐 Secure Boot 与微软证书
Secure Boot 是 UEFI 的核心安全功能，旨在从固件到操作系统强制实施平台的信任链。其主要目的是防止未经授权或恶意的启动组件（如 bootkit）在启动过程中执行。
从高层来看，Secure Boot 通过在允许 UEFI 可执行文件运行之前对其进行加密验证来工作。此验证使用固件维护的两个数据库：
- db：包含受信任的 Authenticode 哈希和受信任的根证书。
- dbx：包含已吊销或明确不受信任的哈希和证书。
UEFI 应用程序在满足以下任一条件时被允许执行：
- 其 Authenticode 哈希与 db 中的某一项匹配，或
- 其证书链可验证至 db 中存在的受信任根证书，且不在 dbx 中。
默认情况下，大多数系统在 db 中信任以下证书：
- Microsoft Corporation UEFI CA 2011 - 用于签署第三方 UEFI 组件，包括 Linux shim。
- Microsoft Windows Production PCA 2011 - 用于签署 Windows 引导加载程序。
- 一个或多个 OEM 自有证书。
与 CVE-2025-3052 相关的易受攻击模块使用 Microsoft Corporation UEFI CA 2011 证书签名。由于该证书在各厂商和平台上被广泛信任，任何使用它签名的应用程序都可以在大多数 UEFI 系统上无需用户交互即可执行。这种广泛的信任显著放大了此类模块中漏洞的影响，因为它实际上绕过了 Secure Boot 预期的保护保证。
🔎 模块发现与侦察
该易受攻击的 UEFI 模块最初是在对上传至公开恶意软件仓库（尤其是 VirusTotal）的 UEFI 二进制文件进行大规模分析时发现的。虽然该模块首次公开提交发生在 2024 年 11 月，但对其 Authenticode 签名的检查显示，它早在 2022 年 10 月就已被签名，这表明该二进制文件在被检测到之前可能已经流传了相当长的时间。
分析期间观察到的原始文件名为 Dtbios-efi64-71.22.efi。对嵌入字符串、证书元数据和文件行为的检查强烈表明，该模块由 DT Research, Inc 开发，该公司专门从事加固型移动计算设备。
进一步的逆向工程显示，该模块是一个 BIOS 刷写工具，旨在从磁盘读取固件映像并将其写入系统 ROM。尽管最初是为 DT Research 硬件设计的，但该模块并不局限于特定平台，可以在任何信任微软第三方 UEFI 证书的系统上执行。
侦察期间的一个关键线索是 IhisiParamBuffer NVRAM 变量的存在。该变量与基于 Insyde 的固件实现密切相关，并且此前曾涉及 Binarly 披露的其他漏洞（例如 BRLY-2022-023 和 BRLY-2023-005）。它的存在立即暗示了一类潜在的 NVRAM 相关问题。
💥 发现与利用漏洞
CVE-2025-3052 的根本原因在于未经验证地不安全使用从 NVRAM 变量读取的数据。具体而言：
- UEFI 应用程序检索 IhisiParamBuffer NVRAM 变量的值。
- 该值被当作受信任指针，并存储在地址 0xf7a0 处的全局变量中。
- 代码随后在 global + 0x18 处执行内存写操作，将该地址设置为零。
- 后续还有更多写操作，全部源自同一个攻击者可控的 NVRAM 值。
- 在任何环节都没有应用边界检查、合理性验证或访问控制。
因此，能够控制 IhisiParamBuffer 变量的攻击者便获得了影响这些写入发生在内存中位置的能力。虽然该写原语受到一定限制，通常只允许向任意地址写入零或小常量，但它仍足以破坏关键固件状态。
在 Binarly 的概念验证中，攻击目标是全局变量 gSecurity2，它保存着指向 Security2 Architectural Protocol 的指针（关于此特定利用技术的详细说明，请参考以下仓库“TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption”）。LoadImage 服务会查询该协议以强制执行 Secure Boot 策略，这意味着用空指针覆盖 gSecurity2 实际上会在运行时禁用 Secure Boot 检查。至关重要的是，这种绕过对操作系统是透明的：一旦启动完成，Secure Boot 在操作系统层面仍显示为已启用，尽管它在固件层面已被完全中和。
一个重要细节是，在基于 Insyde 的平台上，IhisiParamBuffer 变量通常被锁定为只读，这实际上在没有额外漏洞的情况下阻止了在这些系统上的利用。具有讽刺意味的是，这意味着最初由 IBV 引入易受攻击变量模式的厂商反而是暴露最少的，而所有其他平台仍面临风险。对于变量被锁定的情况，可以串联诸如 BRLY-2023-005 之类的绕过方法，先获得对该变量的写访问权限，然后再继续利用。在变量可直接写入的系统上，攻击则简单直接且高度可靠。
🎯 攻击流程
以下描述了利用 CVE-2025-3052 的端到端攻击，假设攻击者具有操作系统级访问权限：
- 设置 NVRAM 变量：攻击者从操作系统将 IhisiParamBuffer NVRAM 变量设置为任意目标地址，使其指向 gSecurity2。
- 注册载荷：攻击者在 UEFI Boot Manager 中注册易受攻击的已签名模块（或用它替换现有的操作系统加载程序），并额外注册第二个包含实际载荷的未签名模块。
- 重启：系统重启后，固件进入 Boot Device Selection (BDS) 阶段并开始执行已注册的启动项。
- 执行：易受攻击的已签名模块首先运行。其受限的写原语被用来用 null 覆盖 gSecurity2，从而禁用 Secure Boot 强制机制。检查被中和后，固件继续加载并执行未签名载荷模块，使攻击者在 DXE 阶段结束时、操作系统尚未来得及建立自身防御之前获得任意代码执行能力。
📦 受影响的模块
微软确定共有 14 个不同的 UEFI 模块受到影响，并通过将其哈希添加到 Secure Boot dbx 中来缓解该问题。
| Module Name | Authenticode SHA-256 Hash |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
🤝 研究与协作
正在做类似的事情？正在研究 UEFI、内核安全、漏洞利用或其他有趣的安全主题？如果你需要帮助开发漏洞利用、探索某种技术，或者只是想交流想法，欢迎随时联系。我始终乐于讨论研究、尽我所能提供帮助，并就有趣的项目开展协作。欢迎通过 LinkedIn 与我联系。