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.
