UEFI-BIOS-Lücken: SecureBoot-Umgehung und Firmware-Austausch möglich

Zwei unterschiedliche Sicherheitslücken in diversen UEFI-BIOS-Versionen mehrerer Anbieter ermöglichen die Umgehung des SecureBoot-Mechanismus. In UEFI-BIOSen von Insyde können Angreifer sogar die Firmware austauschen. Verwundbare Systeme lassen sich damit vollständig kompromittieren. Proof-of-Concept-Code dafür ist öffentlich verfügbar. Systemhersteller arbeiten an BIOS-Updates zum Schließen der Lücken.

In beiden nun bekannt gewordenen Fällen gehen die Schwachstellen auf den Missbrauch von nicht geschützten NVRAM-Variablen zurück. Die können Angreifer manipulieren, obwohl das UEFI-BIOS sie als vertrauenswürdig behandelt – was die Kompromittierung von Systemen ermöglicht.

UEFI-Komponenten unterschiedlicher Hersteller verwundbar

UEFI-Firmware setzt sich aus mehreren Komponenten zusammen, die oftmals von mehreren Herstellern stammen. Wie das CERT in einer Sicherheitsmitteilung vom Dienstag dieser Woche erklärt, lässt sich aufgrund der Schwachstellen in den UEFI-Firmware-Apps „DTBios“ und „BiosFlashShell“ von DTResearch SecureBoot umgehen. „Die Schwachstelle entspringt der unsachgemäßen Handhabung einer Laufzeit-NVRAM-Variable, die beliebig geschrieben werden kann. Das kann kritische Firmware-Strukturen verändern, einschließlich des globalen Security2-Architektur-Protokolls, das die SecureBoot-Verifizierung verwendet. Da die betroffenen UEFI-Apps von der Microsoft UEFI-Zertifizierungsstelle signiert sind, kann diese Schwachstelle auf jedem UEFI-kompatiblen System ausgenutzt werden, sodass unsignierter Code während des Bootvorgangs ausgeführt werden kann“, fasst das CERT das Problem zusammen (CVE-2025-3052 / EUVD-2025-17820, CVSS 8.2, Risiko „hoch„).

Etwas konkreter lautet die Beschreibung, dass die Microsoft-signierten UEFI-Apps die NVRAM-Variable „IhisiParamBuffer“ als Zeiger für Speicheroperationen einsetzt – einschließlich dem Überschreiben des globalen Sicherheitsparameters „gSecurity2“. Dadurch lässt sich die Security2-Architektur-Protokoll-basierte Verifikation umgehen, die die LoadImage-Funktion zum Erzwingen von SecureBoot nutzt, und jedwede unsignierte UEFI-Binärdatei unabhängig von der SecureBoot-Einstellung des UEFI-Bios ausführen. Einige Implementierungen verriegeln die Variable „IhisiParamBuffer“ früh im Boot-Prozess („lock“ der Variablen), wo das nicht stattfindet, lässt sich die Lücke jedoch missbrauchen. Die Entdecker der Schwachstelle von Binarly haben eine tiefergehende Analyse online gestellt. Microsoft hat 14 neue Hashes zu der DBX-Datenbank der „verbotenen Signaturen“ hinzugefügt, die das Ausführen der verwundbaren UEFI-Apps unterbinden sollen. Abhilfe schaffen Software-Updates der Anbieter. Nach derzeitigem Kenntnisstand ist das DTResearch, die aktualisierte Komponenten „DTBios“ und „BiosFlashShell“ bereitstellt, insbesondere für die Insyde-BIOSse. Das CERT pflegt eine Liste mit betroffenen und nicht betroffenen Herstellern in der Sicherheitsmitteilung.

Schwachstelle in Insyde H2O-UEFI-App

In einer Insyde H2O UEFI Firmware-App können Angreifer hingegen aufgrund unsicherer Nutzung einer NVRAM-Variable digitale Zertifikate einschleusen. Das CERT fasst in seiner Mitteilung die Details zusammen. Die Firmware-Apps betrachten die Variable „SecureFlashCertData“ als vertrauenswürdigen Speicher für digitale Zertifikate in der Vertrauenskette. Angreifer können darin jedoch eigene Zertifikate ablegen und in der Folge beliebige Firmware laufen lassen, die damit zertifiziert ist – bereits im frühen BBoot-Prozessinnerhalb der UEFI-Umgebung (CVE-2025-4275 / EUVD-2025-18070, CVSS 7.8, Risiko „hoch„). Der Entdecker der Lücke hat ihr einen Spitznamen gegeben, „Hydroph0bia“ als Wortspiel zu „Insyde H2O“ (H₂O als chemische Summenformel für Wasser). In seiner eigenen detaillierten Analyse stellt er auch Proof-of-Concept-Code (PoC) bereit, der den Missbrauch der Schwachstelle demonstrieren soll.

Das Problem rührt daher, dass einige UEFI-Firmware-Apps dem Inhalt der Variable „SecureFlashCertData“ vertrauen, obwohl sie nicht verriegelt ist. „Das Problem stammt daher, dass die Entwickler von Insyde H2O auf flüchtigen NVRAM für den vertrauenswürdigen Speicher für den Datenaustausch zwischen den einzelnen Stationen zum Laden der Zertifikate durch die Firmware und der Verifikation der Signaturen von Plattform-Tools und Update-Kapseln setzen. Durch den Einsatz üblicher Bibliotheksfunktionen wie ‚LibGetVariable‘ hat ‚LoadImage‘ keine Möglichkeit sicherzustellen, dass die genutzten NVRAM-Variablen tatsächlich flüchtig sind und zuvor von der Firmware selbst gesetzt wurden. Die Übernahme wird dadurch so trivial wie ’setze dieselben Variablen als nicht-flüchtig aus der Betriebssystemumgebung‘, was das PoC-Tool an der administrativen Windows-Eingabeaufforderung vorführt. Auch andere Varianten zum Beschreiben der Variablen als nicht-flüchtiges NVRAM (wie das Linux-efivars-Subsystem) funktionieren genauso“, erklärt der Autor Nikolai Schlej.

Auch hier müssen Firmware-Updates, die von den Herstellern stammen und die betroffenen UEFI-Module aktualisieren, zum Abdichten der Sicherheitslücken her.

Das CERT weist darauf hin, dass das Sperren oder Verriegeln von UEFI-Variablen nur in einigen Firmware-Implementierungen unterstützt wird. Es ist zudem schlecht dokumentiert und in einigen Referenzimplementierung gar nicht verfügbar, die Hersteller an ihre Systeme anpassen. Die Mitteilung des CERTs enthält ebenfalls eine Lücke von betroffenen Herstellern. Die Insyde-H20-Software ist tatsächlich weiter verbreitet.

SecureBoot lässt sich immer wieder mal umgehen, da Fehler in der Implementierung von UEFI-Firmware Sicherheitslücken aufreißen, die Angreifer attackieren können. Etwa Ende 2023 wurde die BIOS-Lücke „LogoFail“ bekannt. Angriffe waren dort jedoch nicht ganz so trivial, da dazu mit Schadcode präparierte Logos in die EFI-Systempartition (ESP) oder in einen unsignierten Teil der Firmware verankert werden müssen.

(dmk)