Démontre le contournement de Secure Boot CVE-2022-34301 via le UEFI Shell signé Eurosoft (esdiags.efi), en utilisant la commande mm pour annuler gSecurity2 et charger des applications UEFI non signées.
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Contournement de Secure Boot via un Shell UEFI signé et une corruption de gSecurity2.
Ce dépôt illustre la technique BYOVUA (Bring Your Own Vulnerable UEFI Application) en exploitant CVE-2022-34301, une vulnérabilité de contournement de Secure Boot dans l'environnement de diagnostic UEFI Eurosoft Pc-Check.
Dans ce cas, le composant approuvé par Secure Boot est esdiags.efi, un Shell UEFI distribué dans le cadre du produit de diagnostic matériel Pc-Check UEFI d'Eurosoft, signé par une chaîne de certificats approuvée par l'UEFI Third Party Certificate Authority de Microsoft. Une fois exécuté, ce shell expose la commande mm (memory modify) et fournit donc des capacités de lecture et d'écriture arbitraires en mémoire durant la phase de démarrage pré-OS.
Cette primitive peut ensuite être utilisée pour localiser et neutraliser le pointeur global gSecurity2 dans le cœur DXE. En conséquence, la vérification des images UEFI suivantes est désactivée, permettant le chargement d'applications UEFI non signées, des bootkits, malgré l'activation de Secure Boot.
BYOVUA est l'équivalent UEFI de la technique BYOVD (Bring Your Own Vulnerable Driver) utilisée au niveau du noyau. Au lieu d'apporter un pilote noyau signé comportant une vulnérabilité, l'attaquant apporte une application UEFI signée - dans ce cas, un Shell UEFI complet - qui contient des fonctionnalités capables de compromettre Secure Boot.
Comme l'application est signée avec une chaîne de certificats approuvée par Secure Boot, elle est acceptée sans contestation, ce qui la rend approuvée sur tout système incluant l'UEFI Third Party Certificate Authority de Microsoft dans sa base de données Secure Boot (db) - c'est-à-dire pratiquement tous les PC compatibles UEFI livrés au cours de la dernière décennie. Une fois en cours d'exécution, ses commandes intégrées fournissent à l'attaquant un accès direct au matériel et à la mémoire qui opère avant le chargement du système d'exploitation, dans un environnement où les contrôles de sécurité modernes (ASLR, DEP, protections du noyau) n'existent tout simplement pas.
esdiags.efi est un Shell UEFI distribué dans le cadre de Pc-Check UEFI d'Eurosoft, un produit de diagnostic matériel pré-démarrage utilisé par les fabricants de PC, les organisations de services et les équipes informatiques pour les tests de systèmes bare-metal.
| Propriété | Valeur |
|---|---|
| Fichier | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| Éditeur | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| Signature | Microsoft Corporation UEFI CA 2011 (Third Party) |
| Découverte | Eclypsium (Mickey Shkatov, Jesse Michael) - Août 2022 |
| Présentation | DEF CON 30 - "One Bootloader to Load Them All" |
| Révocation | Ajouté à la DBX via Microsoft KB5012170 (Août 2022) |
La vulnérabilité n'est pas un bug - c'est un défaut de conception. Les Shells UEFI sont des outils de diagnostic légitimes qui n'ont jamais été conçus pour s'exécuter dans des environnements Secure Boot. Cependant, en les signant avec un certificat approuvé par Microsoft et en les distribuant dans le cadre de produits commerciaux, les éditeurs ont involontairement créé un contournement signé de Secure Boot.
Le problème central : un binaire signé approuvé par Secure Boot fournit des capacités de lecture/écriture mémoire non restreintes via ses commandes intégrées. Cette combinaison brise tout le modèle de confiance de Secure Boot.
La commande mm (memory modify) est une commande intégrée standard du Shell UEFI qui fournit un accès direct en lecture et en écriture à la mémoire système. Elle est documentée dans la UEFI Shell Specification (Section 5.3).```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| Paramètre | Description |
|-----------|-------------|
| `Address` | Adresse mémoire cible |
| `Value` | Valeur à écrire (omettre pour une lecture seule) |
| `-w` | Largeur : 1, 2, 4 ou 8 octets |
| `-MEM` | Accès à la mémoire système |
| `-MMIO` | E/S mappées en mémoire |
| `-IO` | Accès au port d'E/S |
| `-n` | Non interactif (aucune invite pour l'adresse suivante) |
---
<div id='gsecurity2'/>
### ***gSecurity2 et le protocole d'architecture de sécurité***
La vérification des images de démarrage sécurisé dans UEFI est assurée par les [Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols), définis dans la spécification UEFI Platform Initialization (PI).
Le cœur DXE (DxeMain) maintient un pointeur global appelé [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252), qui pointe vers la structure `EFI_SECURITY2_ARCH_PROTOCOL`. Ce protocole contient un unique pointeur de fonction - `FileAuthenticationState` - qui est appelé par `LoadImage()` chaque fois qu'une image UEFI est chargée :```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
Lorsque LoadImage() est appelé, le cœur DXE vérifie :```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
En définissant `gSecurity2 = NULL`, la vérification `if` échoue et `FileAuthenticationState` n'est jamais appelée. La vérification de l'image est complètement ignorée - **Secure Boot reste "activé" mais n'est plus appliqué**. Des applications UEFI non signées peuvent alors être chargées librement.