EFI (application UEFI) : fichier .efi

Une application EFI est un exécutable lancé directement par le micrologiciel UEFI (Unified Extensible Firmware Interface) avant même que le système d’exploitation ne démarre. C’est précisément ce format qui constitue le bootloader lui-même (bootmgfw.efi sous Windows, grubx64.efi pour GRUB sous Linux), la première étape logicielle réellement exécutée après l’initialisation du matériel.

Le format reprend le conteneur Portable Executable des DLL et EXE Windows classiques, avec la même signature d’en-tête “MZ”, mais cible un sous-système et un jeu d’API propres à l’environnement UEFI : les services de démarrage (Boot Services) et d’exécution (Runtime Services) définis par la spécification, distincts des API disponibles une fois le système d’exploitation réellement chargé.

S’exécutant avant tout système d’exploitation et ses propres protections, une application EFI compromise (bootkit UEFI) constitue l’un des points d’implantation les plus persistants d’une attaque : un bootkit placé sur la partition système EFI (ESP), comme BlackLotus, reste en place tant que cette partition n’est pas reformatée, mais une réinstallation complète du système l’élimine (une clé MOK enrôlée par l’attaquant dans la mémoire du micrologiciel peut toutefois subsister et doit être retirée). Seuls les implants logés dans la mémoire flash SPI de la carte mère, comme LoJax découvert en 2018, échappent à une réinstallation.

Architecture et chemin de démarrage par défaut

Comme tout fichier PE, un .efi indique son processeur cible dans le champ Machine de son en-tête (0x8664 pour x64, 0xAA64 pour ARM64, 0x14C pour x86 32 bits) et son rôle dans le champ Subsystem : 10 pour une application EFI, 11 et 12 pour les pilotes de services de démarrage et d’exécution, 13 pour une image de ROM EFI. Un micrologiciel x64 refuse donc un .efi compilé pour ARM64.

Quand aucune entrée de démarrage n’est configurée, par exemple sur une clé USB, le micrologiciel cherche un chargeur à un chemin normalisé qui dépend de l’architecture : \EFI\BOOT\BOOTX64.EFI sur x64, \EFI\BOOT\BOOTAA64.EFI sur ARM64. C’est pour cela qu’une clé d’installation copiée à la main démarre sans configuration.

Secure Boot, shim et révocations

Secure Boot, le mécanisme de vérification introduit par la spécification UEFI, valide la signature cryptographique de chaque application EFI avant de l’exécuter, une défense conçue spécifiquement contre ce risque de substitution, en n’autorisant le démarrage que de bootloaders signés par une autorité de confiance enregistrée dans le micrologiciel.

Sur un PC livré avec Windows, la base de signatures autorisées (db) du micrologiciel contient des certificats Microsoft. Pour démarrer Linux avec Secure Boot actif, les distributions utilisent shim, un petit chargeur EFI signé par l’autorité Microsoft UEFI CA (prévue pour les applications UEFI tierces), qui contient la clé de la distribution et vérifie à son tour GRUB et le noyau, ou une clé MOK (Machine Owner Key) ajoutée par l’utilisateur.

Une signature valide ne suffit pas si le binaire signé est vulnérable. BlackLotus, analysé par ESET en 2023, contournait Secure Boot en installant d’anciens gestionnaires de démarrage Windows légitimement signés mais vulnérables (CVE-2022-21894), qui n’étaient pas encore révoqués. La correction de la faille associée CVE-2023-24932 passe par la liste de révocation DBX : Microsoft y ajoute le certificat « Windows Production PCA 2011 », ce qui interdit tous les gestionnaires de démarrage signés par lui, après avoir installé un gestionnaire signé par le nouveau certificat « Windows UEFI CA 2023 ».