CVE-2025-3052 — Updated!
Forschung zu CVE-2025-3052, einer Insyde-Firmware-Schwachstelle, die eine beliebige Schreibprimitive offenlegt, mit der sicherheitskritische Zeiger modifiziert werden können.
🐞 CVE-2025-3052: IhisiParamBuffer-Speicherbeschädigung
Dieses Repository bündelt Forschungsmaterial zu CVE-2025-3052, einer Speicherbeschädigungsschwachstelle in einem UEFI-Modul, das mit Microsofts Drittanbieter-Zertifikat signiert ist und es einem Angreifer ermöglicht, sicherheitskritische Firmware-Strukturen zu beschädigen, die Secure-Boot-Durchsetzung zu neutralisieren und beliebigen unsignierten Code auszuführen, bevor das Betriebssystem geladen wird. Es enthält eine technische Analyse der Grundursache und der Ausnutzungstechnik, reale und zu Lehrzwecken dienende verwundbare Binärdateien sowie unterstützende Dokumentation, die Forschern helfen soll, diese Schwachstellenklasse zu verstehen, zu reproduzieren und mit ihr zu experimentieren.
📑 Inhaltsverzeichnis
- Ursprüngliche Entdeckung & offizielle Referenzen
- Verwundbare Binärdateien (real / zu Lehrzwecken)
- Schwachstellenübersicht (Analyse, Ausnutzung, PoC)
🧠 Ursprüngliche Entdeckung & offizielle Referenzen
CVE-2025-3052 wurde ursprünglich vom Binarly Research Team entdeckt und verantwortungsvoll offengelegt. Offizielle und Community-Referenzen:
- Binarly Research Blog (10. Juni 2025)
- Community-Referenzsammlung
🐜 Verwundbare Binärdateien
Dieses Repository enthält zwei verwundbare Binärdateien, die mit unterschiedlichen Forschungs- und Lernzielen bereitgestellt werden.
🧨 Reale verwundbare Binärdatei
Diese Binärdatei repräsentiert die Schwachstelle, wie sie in freier Wildbahn existierte.
- Ursprüngliche verwundbare UEFI-Anwendung, die von CVE-2025-3052 betroffen ist.
- Vorgesehen für reale Analyse und Reverse Engineering.
- Signiert mit Microsofts Drittanbieter-UEFI-Zertifikat.
- Extrahiert aus öffentlichen Malware-Repositories:
🎓 Verwundbare Binärdatei zu Lehrzwecken
- Vollständig kompilierbarer Quellcode einer vereinfachten UEFI-Anwendung zu Lehrzwecken.
- Reproduziert dieselbe Schwachstellengrundlage wie die reale Binärdatei.
- Entwickelt, um Anfängern zu helfen:
- Sich schrittweise der Analyse der Original-Binärdatei zu nähern.
- Aufwändiges Reverse Engineering in frühen Phasen zu vermeiden.
- Die Mechanismen der Schwachstelle zu verstehen.
🧪 Schwachstellenübersicht (Analyse, Ausnutzung, PoC)
CVE-2025-3052 ist eine Secure-Boot-Bypass-Schwachstelle, die UEFI-Systeme betrifft und durch den unsicheren Umgang mit Daten verursacht wird, die aus einer NVRAM-Variable innerhalb einer signierten UEFI-Anwendung abgerufen werden. Die Schwachstelle ermöglicht es einem Angreifer, sicherheitskritische Firmware-Strukturen während des Startvorgangs zu beschädigen, wodurch die UEFI-Vertrauenskette effektiv durchbrochen und die Ausführung unsignierten Codes ermöglicht wird, bevor das Betriebssystem geladen wird.
Was diese Schwachstelle besonders wirkungsvoll macht, ist nicht nur die Art des Fehlers selbst – ein Speicherbeschädigungs-Primitiv –, sondern der Kontext, in dem er existiert: ein UEFI-Modul, das mit Microsofts Drittanbieter-UEFI-Zertifikat signiert ist, welches auf der überwiegenden Mehrheit moderner Systeme standardmäßig vertraut wird. Infolgedessen erfolgt die Ausnutzung in einer der frühesten und am höchsten privilegierten Ausführungsphasen der Plattform, noch vor den Sicherheitskontrollen auf Betriebssystemebene.
🔐 Secure Boot & Microsoft-Zertifikate
Secure Boot ist eine zentrale Sicherheitsfunktion von UEFI, die dazu dient, die Vertrauenskette der Plattform von der Firmware bis zum Betriebssystem durchzusetzen. Ihr Hauptzweck ist es, zu verhindern, dass nicht autorisierte oder bösartige Startkomponenten wie Bootkits während des Startvorgangs ausgeführt werden.
Auf hoher Ebene funktioniert Secure Boot, indem UEFI-Executables kryptografisch validiert werden, bevor sie ausgeführt werden dürfen. Diese Validierung erfolgt anhand zweier von der Firmware verwalteter Datenbanken:
- db: Enthält vertrauenswürdige Authenticode-Hashes und vertrauenswürdige Stammzertifikate.
- dbx: Enthält widerrufene oder explizit nicht vertrauenswürdige Hashes und Zertifikate.
Eine UEFI-Anwendung darf ausgeführt werden, wenn entweder:
- ihr Authenticode-Hash mit einem Eintrag in db übereinstimmt, oder
- ihre Zertifikatskette bis zu einem vertrauenswürdigen Stammzertifikat in db validiert und nicht in dbx vorhanden ist.
Standardmäßig werden die meisten Systeme mit den folgenden in db als vertrauenswürdig eingestuften Zertifikaten ausgeliefert:
- Microsoft Corporation UEFI CA 2011 – wird zum Signieren von UEFI-Komponenten Dritter verwendet, einschließlich des Linux-shim.
- Microsoft Windows Production PCA 2011 – wird zum Signieren des Windows-Bootloaders verwendet.
- Ein oder mehrere OEM-eigene Zertifikate.
Die mit CVE-2025-3052 verbundenen verwundbaren Module wurden mit dem Zertifikat Microsoft Corporation UEFI CA 2011 signiert. Da diesem Zertifikat hersteller- und plattformübergreifend weit verbreitet vertraut wird, kann jede damit signierte Anwendung auf den meisten UEFI-Systemen ohne Benutzerinteraktion ausgeführt werden. Dieses breite Vertrauen verstärkt die Auswirkungen einer Schwachstelle in einem solchen Modul erheblich, da es die von Secure Boot beabsichtigten Schutzgarantien effektiv umgeht.
🔎 Modulerkennung & Aufklärung
Das verwundbare UEFI-Modul wurde ursprünglich bei einer groß angelegten Analyse von UEFI-Binärdateien entdeckt, die in öffentliche Malware-Repositories hochgeladen wurden, insbesondere VirusTotal. Während die erste öffentliche Einreichung des Moduls im November 2024 erfolgte, ergab die Untersuchung seiner Authenticode-Signatur, dass es bereits im Oktober 2022 signiert worden war, was darauf hindeutet, dass die Binärdatei möglicherweise beträchtliche Zeit vor ihrer Entdeckung im Umlauf war.
Der während der Analyse beobachtete ursprüngliche Dateiname war Dtbios-efi64-71.22.efi. Die Untersuchung eingebetteter Strings, Zertifikatsmetadaten und Dateiverhaltens deutete stark darauf hin, dass das Modul von DT Research, Inc entwickelt wurde, einem Anbieter, der auf robuste mobile Computergeräte spezialisiert ist.
Weiteres Reverse Engineering ergab, dass das Modul ein BIOS-Flash-Dienstprogramm ist, das dazu dient, ein Firmware-Image von der Festplatte zu lesen und in den ROM des Systems zu schreiben. Obwohl ursprünglich für DT-Research-Hardware gedacht, ist das Modul nicht auf eine bestimmte Plattform beschränkt und kann auf jedem System ausgeführt werden, das dem Microsoft-Drittanbieter-UEFI-Zertifikat vertraut.
Ein entscheidender Hinweis während der Aufklärung war das Vorhandensein der NVRAM-Variable IhisiParamBuffer. Diese Variable ist eng mit Insyde-basierten Firmware-Implementierungen verbunden und war zuvor an anderen von Binarly offengelegten Schwachstellen beteiligt (z. B. BRLY-2022-023 und BRLY-2023-005). Ihr Vorhandensein deutete unmittelbar auf eine potenzielle Klasse NVRAM-bezogener Probleme hin.
💥 Auffinden & Ausnutzen der Schwachstelle
Die Grundursache von CVE-2025-3052 liegt in der unsicheren Verwendung von Daten, die ohne Validierung aus einer NVRAM-Variable gelesen werden. Konkret:
- Die UEFI-Anwendung ruft den Wert der NVRAM-Variable IhisiParamBuffer ab.
- Dieser Wert wird als vertrauenswürdiger Zeiger behandelt und in einer globalen Variable an Adresse 0xf7a0 gespeichert.
- Der Code führt anschließend eine Speicherschreiboperation bei global + 0x18 aus und setzt diese Adresse auf null.
- Weitere Schreiboperationen folgen, die alle von demselben angreiferkontrollierten NVRAM-Wert abgeleitet sind.
- Zu keinem Zeitpunkt werden Grenzprüfungen, Plausibilitätsvalidierungen oder Zugriffskontrollen angewendet.
Infolgedessen erlangt ein Angreifer, der die Variable IhisiParamBuffer kontrollieren kann, die Fähigkeit, zu beeinflussen, wo im Speicher diese Schreibvorgänge stattfinden. Obwohl das Schreibprimitiv etwas eingeschränkt ist – typischerweise erlaubt es das Schreiben von null oder kleinen Konstanten an eine beliebige Adresse –, ist es dennoch mächtig genug, um kritischen Firmware-Zustand zu beschädigen.
Im Proof of Concept von Binarly zielt der Angriff auf die globale Variable gSecurity2, die einen Zeiger auf das Security2 Architectural Protocol hält (eine detaillierte Erklärung dieser spezifischen Ausnutzungstechnik findet sich im folgenden Repository „TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption“). Dieses Protokoll wird vom LoadImage-Dienst konsultiert, um die Secure-Boot-Richtlinie durchzusetzen, was bedeutet, dass das Überschreiben von gSecurity2 mit einem Nullzeiger die Secure-Boot-Prüfungen zur Laufzeit effektiv deaktiviert. Entscheidend ist, dass dieser Bypass für das Betriebssystem transparent ist: Nach dem Start erscheint Secure Boot auf Betriebssystemebene weiterhin aktiviert, obwohl es auf Firmware-Ebene vollständig neutralisiert wurde.
Eine wichtige Nuance ist, dass auf Insyde-basierten Plattformen die Variable IhisiParamBuffer typischerweise als schreibgeschützt gesperrt ist, was eine Ausnutzung auf diesen Systemen ohne eine zusätzliche Schwachstelle effektiv verhindert. Ironischerweise bedeutet dies, dass der Anbieter, dessen IBV das verwundbare Variablenmuster ursprünglich eingeführt hat, zu den am wenigsten exponierten gehört, während alle anderen Plattformen gefährdet bleiben. Für Fälle, in denen die Variable gesperrt ist, kann ein Bypass wie BRLY-2023-005 verkettet werden, um Schreibzugriff auf die Variable zu erlangen, bevor mit der Ausnutzung fortgefahren wird. Auf Systemen, auf denen die Variable direkt beschreibbar ist, ist der Angriff unkompliziert und hochzuverlässig.
🎯 Angriffsablauf
Das Folgende beschreibt den End-to-End-Angriff unter Ausnutzung von CVE-2025-3052, wobei ein privilegierter Angreifer mit Zugriff auf Betriebssystemebene vorausgesetzt wird:
- Setzen der NVRAM-Variable: Der Angreifer setzt die NVRAM-Variable IhisiParamBuffer vom Betriebssystem aus auf eine beliebige Zieladresse und richtet sie auf gSecurity2 aus.
- Registrieren der Nutzlast: Der Angreifer registriert das verwundbare signierte Modul im UEFI Boot Manager (oder ersetzt einen vorhandenen OS-Loader damit) und registriert zusätzlich ein zweites unsigniertes Modul, das die eigentliche Nutzlast enthält.
- Neustart: Nach dem Neustart des Systems tritt die Firmware in die Boot Device Selection (BDS)-Phase ein und beginnt mit der Ausführung registrierter Starteinträge.
- Ausführung: Das verwundbare signierte Modul wird zuerst ausgeführt. Sein eingeschränktes Schreibprimitiv wird verwendet, um gSecurity2 mit null zu überschreiben und die Secure-Boot-Durchsetzung zu deaktivieren. Nachdem die Prüfungen neutralisiert sind, fährt die Firmware fort, das unsignierte Nutzlastmodul zu laden und auszuführen, was dem Angreifer beliebige Codeausführung am Ende der DXE-Phase gewährt, bevor das Betriebssystem irgendeine Gelegenheit hat, seine eigenen Verteidigungen aufzubauen.
📦 Betroffene Module
Microsoft stellte fest, dass 14 verschiedene UEFI-Module betroffen waren, und entschärfte das Problem, indem ihre Hashes zur Secure-Boot-dbx hinzugefügt wurden.
| Modulname | Authenticode-SHA-256-Hash |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
🤝 Forschung & Zusammenarbeit
Arbeiten Sie an etwas Ähnlichem? Forschen Sie zu UEFI, Kernel-Sicherheit, Ausnutzung oder einem anderen interessanten Sicherheitsthema? Wenn Sie Unterstützung bei der Entwicklung eines Exploits, beim Erkunden einer Technik benötigen oder einfach Ideen austauschen möchten, zögern Sie nicht, sich zu melden. Ich bin immer offen für den Austausch über Forschung, helfe gerne, wo ich kann, und arbeite an interessanten Projekten mit. Kontaktieren Sie mich gerne auf LinkedIn.