UEFI-BIOS-Lücken: SecureBoot-Umgehung und Firmware-Austausch möglich
close notice
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
.
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-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“ (H2O 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.
Die Woche, in der sich die Überwachungspläne bei uns stapelten
Fraktal, generiert mit MandelBrowser von Tomasz Śmigielski
Liebe Leser*innen,
in Berlin ist zwar die Ferienzeit angebrochen. Sommerliche Ruhe will aber nicht so recht einkehren. Denn auf unseren Schreibtischen stapeln sich die neuen Gesetzesentwürfe der Bundesregierung. Und die haben’s in sich.
Beispiele gefällig?
Staatstrojaner: Künftig soll die Bundespolizei zur „Gefahrenabwehr“ Personen präventiv hacken und überwachen dürfen, auch wenn „noch kein Tatverdacht begründet ist“.
Biometrische Überwachung: Bundeskriminalamt, Bundespolizei und das Bundesamt für Migration und Flüchtlinge sollen Personen anhand biometrischer Daten im Internet suchen dürfen. Auch Gesichter-Suchmaschinen wie Clearview AI oder PimEyes können sie dann nutzen.
Palantir: Bundeskriminalamt und Bundespolizei sollen Datenbestände zusammenführen und automatisiert analysieren dürfen. Das riecht gewaltig nach Palantir – was das Innenministerium in dieser Woche bestätigt hat.
Auch in vielen Bundesländern wird über Palantir diskutiert. In Baden-Württemberg sind die Grünen soeben umgekippt. Keine gewagte Prognose: Andere werden ihre Vorsätze auch noch über Bord werfen.
Die gute Nachricht: In allen drei Bundesländern, die Palantir einsetzen – Bayern, Hessen und Nordrhein-Westfalen -, sind jeweils Verfassungsbeschwerden gegen die Polizeigesetze anhängig. Und auch die Überwachungspläne der Bundesregierung verstoßen ziemlich sicher gegen Grundgesetz und EU-Recht. Wir bleiben dran.
Martin, Sebastian und Chris im Studio. – CC-BY-NC-SA 4.0 netzpolitik.org
Diese Recherche hat für enorm viel Aufsehen gesorgt: Über Monate hinweg hat sich Martin damit beschäftigt, wie Polizeibehörden, Banken und Unternehmen unser Bargeld verfolgen und was sie über die Geldströme wissen. Die Ergebnisse überraschten auch uns, denn sie räumen mit gängigen Vorstellungen über das vermeintlich anonyme Zahlungsmittel auf. Die Aufregung um diese Recherche rührt vielleicht auch daher, dass Behörden nicht gerne darüber sprechen, wie sie Bargeld tracken. Martin selbst spricht von einer der zähsten Recherchen seines Arbeitslebens.
Außerdem erfahrt ihr, wie wir solche Beiträge auf Sendung-mit-der-Maus-Niveau bringen und warum man aus technischen Gründen besser Münzen als Scheine rauben sollte. Wir sprechen darüber, wie wir trotz schlechter Nachrichten zuversichtlich bleiben und warum wir weitere Wände im Büro einziehen. Viel Spaß beim Zuhören!
Und falls wir es in dieser Podcast-Folge noch nicht oft genug erwähnt haben sollten: Wir freuen uns über Feedback, zum Beispiel per Mail an podcast@netzpolitik.org oder in den Ergänzungen auf unserer Website.
In dieser Folge: Martin Schwarzbeck, Sebastian Meineck und Chris Köver. Produktion: Serafin Dinges. Titelmusik: Trummerschlunk.
Hier ist die MP3 zum Download. Wie gewohnt gibt es den Podcast auch im offenen ogg-Format. Ein maschinell erstelltes Transkript gibt es im txt-Format.
Unseren Podcast könnt ihr auf vielen Wegen hören. Der einfachste: in dem Player hier auf der Seite auf Play drücken. Ihr findet uns aber ebenso bei Apple Podcasts, Spotify und Deezer oder mit dem Podcatcher eures Vertrauens, die URL lautet dann netzpolitik.org/podcast.
Wir freuen uns auch über Kritik, Lob, Ideen und Fragen entweder hier in den Kommentaren oder per E-Mail an podcast@netzpolitik.org.
Sicherheitsupdates: IBM Db2 über verschiedene Wege angreifbar
close notice
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
.
Aufgrund von mehreren Softwareschwachstellen können Angreifer IBM Db2 attackieren und Instanzen im schlimmsten Fall vollständig kompromittieren. Um dem vorzubeugen, sollten Admins die abgesicherten Versionen installieren.
Schadcode-Schlupfloch
Am gefährlichsten gilt eine Sicherheitslücke (CVE-2025-33092 „hoch„), durch die Schadcode schlüpfen kann. Die Basis für solche Attacken ist ein von Angreifern ausgelöster Speicherfehler. Wie ein solcher Angriff konkret ablaufen könnten, ist bislang unklar. Davon sind einer Warnmeldung zufolge die Client- und Server-Editionen von Db2 bedroht. Das betrifft die Db2-Versionen 11.5.0 bis einschließlich 11.5.9 und 12.1.0 bis einschließlich 12.1.2.
Eine weitere Schwachstelle (CVE-2025-24970) ist mit dem Bedrohungsgrad „hoch“ eingestuft. Sie betrifft das Application Framework Netty. An dieser Stelle können Angreifer Abstürze provozieren. Auch hier soll ein Special Build Abhilfe schaffen.
Weitere Gefahren
Die verbleibenden Schwachstellen sind mit dem Bedrohungsgrad „mittel“ versehen. An diesen Stellen können Angreifer meist ohne Authentifizierung DoS-Zustände erzeugen, was Abstürze nach sich zieht. Die dagegen gerüsteten Versionen finden Admins in den verlinkten Warnmeldungen (nach Bedrohungsgrad absteigend sortiert):
