返回更新列表
已更新Sep 3, 2026

CVE-2026-25250 — 已更新!

CVE-2026-25250 的分析与利用，这是 Horizon DataSys Reboot Restore 中的一个 Secure Boot 绕过漏洞，其中 shdloader.efi 在未经验证的情况下加载 Shield.efi。

分享

🕷️ CVE-2026-25250：可信引导加载程序链验证不当

一个由 Microsoft 签名的第三方引导加载程序，加载了无签名或完整性验证的二级 EFI 二进制文件，从内部瓦解了 Secure Boot 信任链。

📑 目录

🧠 研究背景

本仓库记录了针对 CVE-2026-25250 的研究，这是一个已向 Microsoft 披露并于 2026 年 4 月分配 CVE 编号的 Secure Boot 绕过漏洞。该漏洞迅速成为当年最重要的固件安全问题之一，原因恰恰在于受影响组件由 Microsoft 签名，因此在绝大多数支持 UEFI 的 Windows 系统中被无条件信任。

该漏洞由 Eclypsium 的 Mickey Shkatov 和 Stanislav Lyakhov 发现，Eclypsium 是业内领先的固件与供应链安全研究团队之一。Mickey Shkatov 是 UEFI 攻击性研究领域的资深人物，是 BootHole（CVE-2020-10713，一个影响几乎所有 Linux 发行版和 Windows 双启动配置的严重 GRUB2 Secure Boot 绕过漏洞）的作者，并与 Jesse Michael 在 DEF CON 30 上共同发表了题为“One Bootloader to Load Them All”的演讲，该演讲系统性地揭示了 Microsoft 签名的第三方引导加载程序如何构成 Secure Boot 生态系统中的一类弱点。

CVE-2026-25250 正属于这一类。

其特别具有启发意义之处在于它的简单性：没有内存破坏，没有固件本身的密码学缺陷，仅仅是一个受信任的二进制文件对下一步加载内容做出了不安全的决定。一个薄弱环节就足以使目标系统的整个 Secure Boot 模型崩溃。

📌 官方参考

CVE-2026-25250 是在分析部署于企业恢复环境中的第三方 UEFI 启动组件时发现的。受影响产品是 Horizon DataSys 的 Reboot Restore 解决方案。

该漏洞由 MITRE 而非 Microsoft 分配编号，因为缺陷位于第三方固件（shdloader.efi）中，而非 Windows 或任何 Microsoft 编写的代码。

官方参考：

🔬 自行复现

Eclypsium 的披露（由发现团队在 LinkedIn 上发布）提供了足够的上下文来识别受影响软件，并可直接从供应商网站下载。

Horizon DataSys Reboot Restore 安装程序可公开获取，在测试系统上安装后会将 shdloader.efi 和 Shield.efi 同时放入 EFI 系统分区，可在其中进行静态分析或运行时观察。

推荐的实验室环境：

Windows 10/11 虚拟机（QEMU 或 VMware）
├── Secure Boot：已启用
├── Horizon DataSys Reboot Restore：已安装
├── 通过以下命令访问 ESP：mountvol X: /S
└── 目标：
	HorizonDataSys
        X:\EFI\shdloader.efi ← 已签名、受信任、加载下一阶段
        X:\EFI\Shield.efi    ← 加载时无任何验证

安装后，可通过 sigcheck.exe（Sysinternals）或 pesign 确认 shdloader.efi 已由 Microsoft CA 2011 签名。Shield.efi 加载路径中缺少任何 LoadImage / StartImage 调用，这一点在静态分析中即可立即发现。

🐜 受影响引导链

该漏洞影响的是一个多阶段引导链，而非单个二进制文件。

🧨 阶段 1 - 受信任的引导加载程序

  • shdloader.efi
    • 已使用 Microsoft UEFI CA 2011 数字签名
    • 被 Secure Boot 固件策略无条件信任
    • 由 Horizon DataSys 软件安装到 ESP

⚠️ 阶段 2 - 未经验证的有效载荷

  • Shield.efi
    • 由 shdloader.efi 在启动时动态加载
    • ❌ 无签名验证
    • ❌ 无完整性检查
    • ❌ 未使用 UEFI LoadImage / StartImage API
    • ✅ 可被任何本地管理员自由替换

📌 关键观察

该漏洞不在于固件本身，而在于受信任引导加载程序的逻辑——一个已被固件批准的二进制文件——选择通过绕过所有安全检查的代码路径来加载二级二进制文件。

固件
  └── 验证 shdloader.efi          ✅ Microsoft CA 2011，受信任
        └── ManualPEParse(Shield.efi) ❌ 无 LoadImage，无签名检查
              └── EntryPoint()        💥 攻击者控制的代码，操作系统启动前

Secure Boot 边界的安全强度，取决于其所信任的最不谨慎的二进制文件。

🧪 漏洞概述

CVE-2026-25250 是一个 Secure Boot 绕过漏洞，由启动过程中加载的二级 EFI 二进制文件验证不当所致。受影响的引导加载程序（shdloader.efi）已由 Secure Boot 签名并信任，但通过手动 PE 解析例程加载 Shield.efi，且不进行任何形式的密码学验证。

这是一个设计与信任模型缺陷——一个受信任组件做出了不安全的决定，使所有下游保护措施全部失效。

🔐 Secure Boot 与信任模型

Secure Boot 强制实施一条信任链，其中启动序列中执行的每个组件在控制权转移前都必须经过验证。该模型只有在链中每个受信任的二进制文件都遵守这一约定时才成立：

固件 → 验证引导加载程序 → 引导加载程序仅执行经过验证的代码

CVE-2026-25250 破坏了第二个环节：

固件 → 验证 shdloader.efi（✅ 受信任）
             ↓
           shdloader.efi → 加载 Shield.efi（❌ 未验证）
                             ↓
                           任意未签名代码在启动前执行

一旦受信任的二进制文件引入了未经验证的执行路径，Secure Boot 在固件层面的强制措施就变得无关紧要。

🧬 根本原因分析

分类为：

步骤是否执行说明
在 ESP 上定位 Shield.efi✅标准文件系统访问
将文件读入内存✅-
手动解析 PE 头✅自定义实现
验证签名❌未执行
对照 db / dbx 检查❌未执行
调用 LoadImage / StartImage❌完全绕过
将执行权转移到入口点✅直接调用

缺少 LoadImage / StartImage 是根本原因。这些 UEFI 启动服务是 Secure Boot 策略执行的集成点，绕过它们就意味着绕过一切。

💥 利用过程

利用需要本地管理员权限和一次重启。

  1. 挂载 EFI 系统分区
  2. 将 Shield.efi 替换为任意未签名的 EFI 二进制文件
  3. 重启

下次启动时，shdloader.efi 执行（受固件信任），加载攻击者控制的二进制文件并转移执行权——在操作系统启动前、EDR 加载前、任何测量启动策略执行前——Secure Boot 不会提出任何异议。

可实现：

  • 持久性 UEFI 启动套件，可抵御操作系统重装和全盘擦除。
  • 对任何操作系统层安全工具不可见的早期植入。
  • 完全规避内核模式保护（EDR、PatchGuard、VBS/HVCI）。

📚 资源

🤝 研究与协作

正在研究类似课题？从事 UEFI、内核安全、漏洞利用或其他有趣的安全主题研究？如果您需要协助开发漏洞利用、探索某项技术，或只是想交流想法，欢迎随时联系。我一直乐于讨论研究、在力所能及之处提供帮助，并协作开展有趣的项目。欢迎通过 LinkedIn 与我联系。

阅读更多

分类

持久化机制漏洞分析漏洞利用二进制分析学习与教育固件分析