themalwareguardian/cve-2022-34301Demonstriert die Umgehung von Secure Boot über CVE-2022-34301 mittels der von Eurosoft signierten UEFI-Shell (esdiags.efi), wobei der Befehl mm verwendet wird, um gSecurity2 zu nullifizieren und unsignierte UEFI-Anwendungen zu laden.
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Secure Boot bypass via signierter UEFI Shell und gSecurity2-Korruption.
Dieses Repository demonstriert die BYOVUA (Bring Your Own Vulnerable UEFI Application)-Technik durch die Ausnutzung von CVE-2022-34301, einer Secure-Boot-Bypass-Schwachstelle in der Eurosoft Pc-Check UEFI-Diagnoseumgebung.
In diesem Fall ist die von Secure Boot vertraute Komponente esdiags.efi, eine UEFI Shell, die als Teil von Eurosofts Pc-Check UEFI-Hardware-Diagnoseprodukt vertrieben wird und von einer Zertifikatskette signiert ist, der Microsofts UEFI Third Party Certificate Authority vertraut. Nach der Ausführung stellt diese Shell den mm-Befehl (memory modify) bereit und bietet somit beliebige Speicher-Lese- und Schreibfähigkeiten während der Pre-OS-Boot-Phase.
Dieses Primitiv kann dann verwendet werden, um den gSecurity2-Global-Pointer im DXE-Kern zu lokalisieren und zu nullifizieren. Infolgedessen wird die nachfolgende UEFI-Image-Verifikation deaktiviert, wodurch unsignierte UEFI-Anwendungen, Bootkits, trotz aktiviertem Secure Boot geladen werden können.
BYOVUA ist das UEFI-Äquivalent zur BYOVD-Technik (Bring Your Own Vulnerable Driver), die auf Kernel-Ebene verwendet wird. Anstatt einen signierten Kernel-Treiber mit einer Schwachstelle mitzubringen, bringt der Angreifer eine signierte UEFI-Anwendung mit - in diesem Fall eine vollständige UEFI Shell -, die Funktionalität enthält, die Secure Boot untergraben kann.
Da die Anwendung mit einer Zertifikatskette signiert ist, der Secure Boot vertraut, wird sie ohne Fragen akzeptiert und ist somit auf jedem System vertrauenswürdig, das die Microsoft UEFI Third Party Certificate Authority in seiner Secure-Boot-Datenbank (db) enthält - was praktisch auf jedem UEFI-fähigen PC zutrifft, der im letzten Jahrzehnt ausgeliefert wurde. Einmal ausgeführt, bieten ihre integrierten Befehle dem Angreifer direkten Hardware- und Speicherzugriff, der vor dem Laden des Betriebssystems operiert, in einer Umgebung, in der moderne Sicherheitskontrollen (ASLR, DEP, Kernel-Schutzmechanismen) schlicht nicht existieren.
esdiags.efi ist eine UEFI Shell, die als Teil von Eurosofts Pc-Check UEFI vertrieben wird, einem Pre-Boot-Hardware-Diagnoseprodukt, das von PC-Herstellern, Serviceorganisationen und IT-Teams für Bare-Metal-Systemtests verwendet wird.
| Eigenschaft | Wert |
|---|---|
| Datei | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| Hersteller | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| Signierung | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Entdeckung | Eclypsium (Mickey Shkatov, Jesse Michael) - August 2022 |
| Präsentation | DEF CON 30 - "One Bootloader to Load Them All" |
| Widerruf | Hinzugefügt zur DBX via Microsoft KB5012170 (August 2022) |
Die Schwachstelle ist kein Bug - sie ist ein Designfehler. UEFI Shells sind legitime Diagnosewerkzeuge, die niemals dafür gedacht waren, in Secure-Boot-Umgebungen ausgeführt zu werden. Indem die Hersteller sie jedoch mit einem von Microsoft vertrauten Zertifikat signierten und als Teil kommerzieller Produkte vertrieben, schufen sie unbeabsichtigt einen signierten Bypass für Secure Boot.
Das Kernproblem: Eine signierte Binärdatei, der Secure Boot vertraut, bietet uneingeschränkte Speicher-Lese-/Schreibfähigkeiten durch ihre integrierten Befehle. Diese Kombination bricht das gesamte Secure-Boot-Vertrauensmodell.
Der mm-Befehl (memory modify) ist ein standardmäßiger integrierter Befehl der UEFI Shell, der direkten Lese- und Schreibzugriff auf den Systemspeicher bietet. Er ist in der UEFI Shell Specification (Abschnitt 5.3) dokumentiert.```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Parameter | Beschreibung |
|-----------|-------------|
| `Address` | Ziel-Speicheradresse |
| `Value` | Zu schreibender Wert (für Nur-Lesen weglassen) |
| `-w` | Breite: 1, 2, 4 oder 8 Bytes |
| `-MEM` | Systemspeicherzugriff |
| `-MMIO` | Speicherzugeordnete E/A |
| `-IO` | E/A-Port-Zugriff |
| `-n` | Nicht-interaktiv (keine Aufforderung für nächste Adresse) |
---
<div id='gsecurity2'/>
### ***gSecurity2 und das Security Architectural Protocol***
Die Secure-Boot-Image-Verifikation in UEFI wird durch die [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) erzwungen, die in der UEFI Platform Initialization (PI) Specification definiert sind.
Der DXE-Kern (DxeMain) verwaltet einen globalen Zeiger namens [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), der auf die Struktur `EFI_SECURITY2_ARCH_PROTOCOL` zeigt. Dieses Protokoll enthält einen einzigen Funktionszeiger - `FileAuthenticationState` - der von `LoadImage()` bei jedem Laden eines UEFI-Images aufgerufen wird:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
Wenn LoadImage() aufgerufen wird, prüft der DXE-Core:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
Durch das Setzen von `gSecurity2 = NULL` schlägt die `if`-Prüfung fehl und `FileAuthenticationState` wird nie aufgerufen. Die Image-Verifizierung wird vollständig übersprungen – **Secure Boot bleibt „aktiviert", wird aber nicht mehr durchgesetzt**. Unsigned UEFI-Anwendungen können dann frei geladen werden.