themalwareguardian/cve-2022-34302Démontre CVE-2022-34302, un contournement de Secure Boot via le bootloader signé New Horizon Datasys dont le chargeur PE/COFF personnalisé intégré exécute des applications UEFI non signées.
New Horizon Datasys Reboot Restore Boot Loader - Bring Your Own Vulnerable UEFI Application (BYOVUA) - Contournement de Secure Boot via un chargeur d'amorçage signé doté d'un chargeur PE/COFF personnalisé intégré qui charge des applications UEFI non signées.
Ce dépôt illustre la technique BYOVUA (Bring Your Own Vulnerable UEFI Application) en exploitant CVE-2022-34302, une vulnérabilité de contournement de Secure Boot dans le chargeur d'amorçage New Horizon Datasys.
Contrairement aux vulnérabilités basées sur le Shell UEFI (CVE-2022-34301 et CVE-2022-34303), ce chargeur d'amorçage n'expose pas de Shell UEFI. À la place, shdloader.efi implémente son propre chargeur PE/COFF personnalisé qui charge un binaire de second étage (shdmgr.ef_) sans utiliser la fonction LoadImage() du firmware et sans effectuer aucune vérification de signature. Un attaquant n'a qu'à remplacer shdmgr.ef_ par n'importe quelle application UEFI compatible pour obtenir une exécution de code arbitraire avec Secure Boot activé.
Il s'agit de la plus dangereuse des trois vulnérabilités divulguées dans la recherche « One Bootloader to Load Them All ». Comme l'a noté Eclypsium : le contournement est intégré, complètement silencieux, et ne laisse aucune indication visuelle à l'écran - le rendant invisible même sur les systèmes dotés d'un moniteur et indétectable sur les systèmes sans tête tels que les serveurs ou les équipements industriels.
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é présentant une vulnérabilité, l'attaquant apporte une application UEFI signée qui contient des fonctionnalités capables de compromettre Secure Boot.
Comme shdloader.efi est signé avec un certificat approuvé par Microsoft, il est accepté par Secure Boot sans contestation, ce qui le rend approuvé sur tout système qui inclut ce certificat 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, son chargeur PE personnalisé intégré offre à l'attaquant la capacité de charger et d'exécuter du code non signé arbitraire 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.
shdloader.efi est un chargeur d'amorçage UEFI distribué dans le cadre des produits de restauration et de récupération système de New Horizon Datasys (Reboot Restore Rx, RollBack Rx). Son rôle dans la chaîne d'amorçage légitime est de charger un composant de gestion pré-OS (shdmgr.ef_) qui gère les opérations d'instantané et de restauration avant le démarrage du système d'exploitation.
| Propriété | Valeur |
|---|---|
| Fichier | shdloader.efi = EFI/Boot/bootx64.efi |
| Éditeur | New Horizon Datasys Inc |
| Produit | Reboot Restore Rx / RollBack Rx |
| CVE | CVE-2022-34302 |
| Signature | Microsoft Windows UEFI Driver Publisher → Microsoft Corporation UEFI CA 2011 |
| 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é est un défaut de conception dans l'architecture du chargeur d'amorçage. Plutôt que d'utiliser les services d'amorçage LoadImage() et StartImage() du firmware - qui appliquent la vérification de signature Secure Boot - shdloader.efi implémente son propre chargeur PE/COFF personnalisé qui lit, relocalise et exécute shdmgr.ef_ directement à partir des octets bruts du disque, contournant complètement les contrôles de sécurité du firmware.
Le problème fondamental : un binaire signé qui est approuvé par Secure Boot contient son propre chargeur d'image qui ne vérifie pas les signatures. Le firmware valide shdloader.efi comme signé, mais une fois qu'il est en cours d'exécution, il charge shdmgr.ef_ sans aucune vérification. Remplacer shdmgr.ef_ par une application UEFI arbitraire a pour résultat que cette application s'exécute avec un accès matériel complet, tandis que Secure Boot est signalé comme activé.
Cela est fondamentalement différent de CVE-2022-34301 et CVE-2022-34303, où l'attaquant doit interagir avec un Shell UEFI et corrompre manuellement gSecurity2 pour désactiver la vérification. Ici, le contournement est automatique et silencieux - aucune interaction utilisateur, aucune sortie visible, aucune invite de shell.
Le shdloader.efi signé contient sa propre implémentation d'un chargeur d'image PE/COFF. Au lieu d'appeler le service d'amorçage LoadImage() du firmware, qui invoquerait les Security Architectural Protocols et vérifierait la signature de l'image par rapport à la base de données Secure Boot, le chargeur d'amorçage :
\EFI\Boot\shdmgr.ef_ en utilisant le EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.reloc et applique les relocalisations de baseÀ aucun moment de ce processus, le chargeur ne vérifie la signature Authenticode de l'image, ne consulte la base de données Secure Boot (db/dbx), ou n'invoque le EFI_SECURITY2_ARCH_PROTOCOL. L'image est chargée uniquement sur la base de sa validité structurelle PE/COFF.```c
// Pseudocode of what shdloader.efi does internally
//
// NOTE: This is a simplified representation. The actual
// implementation was derived from reverse engineering.