Forschung zu CVE-2025-3052, einer Insyde-Firmware-Schwachstelle, die eine beliebige Schreibprimitive offenlegt, mit der sicherheitskritische Zeiger modifiziert werden können.
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.
CVE-2025-3052 wurde ursprünglich vom Binarly Research Team entdeckt und verantwortungsvoll offengelegt. Offizielle und Community-Referenzen:
Dieses Repository enthält zwei verwundbare Binärdateien, die mit unterschiedlichen Forschungs- und Lernzielen bereitgestellt werden.
Diese Binärdatei repräsentiert die Schwachstelle, wie sie in freier Wildbahn existierte.
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 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:
Eine UEFI-Anwendung darf ausgeführt werden, wenn entweder:
Standardmäßig werden die meisten Systeme mit den folgenden in db als vertrauenswürdig eingestuften Zertifikaten ausgeliefert:
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.
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.
Die Grundursache von CVE-2025-3052 liegt in der unsicheren Verwendung von Daten, die ohne Validierung aus einer NVRAM-Variable gelesen werden. Konkret:
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.
Das Folgende beschreibt den End-to-End-Angriff unter Ausnutzung von CVE-2025-3052, wobei ein privilegierter Angreifer mit Zugriff auf Betriebssystemebene vorausgesetzt wird:
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 |
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.
