CVE-2025-4275 — Mis à jour !
Analyse et exploitation de CVE-2025-4275 (Hydr0ph0bia), une faiblesse de la chaîne de confiance Secure Boot où des variables de firmware sont utilisées pour introduire des certificats contrôlés par l'attaquant et approuvés par les composants de démarrage ultérieurs.
🐞 CVE-2025-4275 : Hydroph0bia SecureFlash Certificate Shadowing
Ce dépôt contient le matériel de recherche lié à CVE-2025-4275, une vulnérabilité de contournement de Secure Boot affectant les firmwares compatibles UEFI basés sur Insyde H2O. Il centralise l'analyse technique de la vulnérabilité, les binaires impliqués dans le problème, ainsi que la documentation et les outils destinés à aider les chercheurs à mieux comprendre, étudier et expérimenter cette vulnérabilité dans des contextes à la fois réels et éducatifs.
📑 Table des matières
- Découverte originale et références officielles
- Présentation de la vulnérabilité (analyse, exploitation, PoC)
🧠 Découverte originale et références officielles
CVE-2025-4275 a été découverte et divulguée de manière responsable par Nikolaj Schlej, avec une coordination assurée via CERT/CC. Références officielles et communautaires :
- Blog du chercheur - Partie 1 (contournement de Secure Boot)
- Blog du chercheur - Partie 2 (prise de contrôle du volume DXE)
- Blog du chercheur - Partie 3 (analyse du correctif)
- Avis officiel d'Insyde (10 juin 2025)
- Collection de références communautaires
🧪 Présentation de la vulnérabilité (analyse, exploitation, PoC)
CVE-2025-4275, surnommée Hydroph0bia (un jeu de mots sur Insyde H2O), est une vulnérabilité de contournement de Secure Boot affectant les firmwares compatibles UEFI construits sur la plateforme Insyde H2O. La vulnérabilité découle d'un défaut de conception dans le sous-système de mise à jour du firmware : un certificat de signature censé être chargé dans une variable NVRAM volatile par un pilote de confiance peut à la place être pré-rempli comme variable non volatile par un attaquant, amenant le firmware à faire confiance à du code externe arbitraire comme s'il avait été signé par Insyde eux-mêmes.
Ce qui rend cette vulnérabilité particulièrement impactante, c'est la combinaison de sa simplicité et de sa portée. L'exploitation ne nécessite que des privilèges d'administrateur local, suffisants pour écrire des fichiers sur la partition système EFI et créer des variables NVRAM, et affecte tout système exécutant un firmware Insyde H2O construit avant le 10 juin 2025. L'attaque est indépendante de l'OEM, ce qui signifie qu'elle s'applique largement à Acer, Dell, Framework, Fujitsu, HP, Huawei, Lenovo, et tout autre vendeur livrant un firmware basé sur Insyde.
🔐 NVRAM et Secure Boot dans Insyde H2O
UEFI fournit une interface abstraite vers le stockage de variables non volatiles connu sous le nom de NVRAM. Une particularité de longue date de cette interface est qu'une variable non volatile avec un nom et un GUID donnés peut coexister avec, et masquer, une variable volatile ayant la même identité. Si du code s'attend à une variable volatile (créée à l'exécution par un pilote de confiance) mais qu'une variable non volatile du même nom existe déjà, la version non volatile peut être consommée à la place. Ce comportement, parfois appelé shadowing des variables NVRAM, est le fondement de cette vulnérabilité.
Le sous-système de mise à jour du firmware d'Insyde H2O repose sur deux variables NVRAM pour transmettre un certificat de signature entre pilotes :
- SecureFlashSetupMode : une variable de déclenchement lue par SecurityStubDxe pour activer la vérification basée sur certificat.
- SecureFlashCertData : une variable transportant le certificat de signature au format EFI_SIGNATURE_LIST, utilisée pour authentifier l'application de mise à jour du firmware (isflash.bin).
Dans le flux attendu, les deux variables sont créées comme volatiles par BdsDxe pendant le processus de mise à jour du firmware. SecurityStubDxe les consomme ensuite pour vérifier que isflash.bin est signé par le certificat d'Insyde avant d'autoriser son exécution. Le défaut critique est que SecurityStubDxe ne valide pas si ces variables sont volatiles ou non volatiles avant de faire confiance à leur contenu.
💣 Shadowing des variables NVRAM
La cause racine de CVE-2025-4275 est que SecurityStubDxe utilise une fonction de bibliothèque générique pour lire SecureFlashSetupMode et SecureFlashCertData au lieu d'appeler directement le service d'exécution GetVariable. Cela signifie qu'il ne peut pas distinguer une variable volatile définie par un BdsDxe de confiance d'une variable non volatile pré-remplie par un attaquant (pour une explication détaillée de cette technique spécifique, se référer au dépôt suivant "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing").
Par conséquent, un attaquant disposant de privilèges d'administrateur local peut :
- Créer une variable de déclenchement SecureFlashSetupMode non volatile avant que le flux de mise à jour du firmware ne commence.
- Créer une variable SecureFlashCertData non volatile contenant un certificat contrôlé par l'attaquant au format EFI_SIGNATURE_LIST.
Au prochain démarrage, SecurityStubDxe trouvera les deux variables, les traitera comme légitimes, et fera confiance à tout exécutable UEFI signé avec le certificat de l'attaquant, contournant ainsi entièrement Secure Boot. Aucune interaction au niveau du firmware, aucun accès matériel, ni exploitation d'une primitive de corruption mémoire n'est nécessaire. La surface d'attaque est simplement l'interface d'écriture NVRAM UEFI, accessible depuis une session OS privilégiée.
💥 Découverte et exploitation de la vulnérabilité
La vulnérabilité a été découverte lors d'une revue de sécurité d'un HUAWEI MateBook 14 2023, exécutant un firmware basé sur Insyde H2O avec Secure Boot, mot de passe firmware, et d'autres fonctionnalités de sécurité modernes activées. Malgré ces protections, l'exploitation complète a été réalisée en utilisant uniquement des privilèges d'administrateur au niveau de l'OS.
La phase d'exploitation initiale nécessite un petit outil Windows (SFCD) qui :
- Acquiert le privilège SeSystemEnvironmentPrivilege nécessaire pour appeler SetFirmwareEnvironmentVariable.
- Crée la variable non volatile SecureFlashCertData contenant un certificat contrôlé par l'attaquant.
- Crée la variable de déclenchement non volatile SecureFlashSetupMode définie à 1.
Après redémarrage, SecurityStubDxe lit les deux variables et commence à faire confiance à tout ce qui est signé par le certificat de l'attaquant. Une démonstration pratique de cette première phase est le chargement d'un pilote UEFI CrScreenshotDxe signé avec un certificat personnalisé, qui capture avec succès une capture d'écran de l'écran de configuration du BIOS, avec Secure Boot activé, comme preuve d'exécution de code arbitraire dans l'environnement du firmware.
Une nuance importante : la variable IhisiParamBuffer présente dans CVE-2025-3052 est souvent verrouillée sur les plateformes basées sur Insyde, rendant l'exploitation directe plus difficile sur celles-ci. CVE-2025-4275 ne nécessite pas qu'une telle variable soit accessible en écriture et ne dépend d'aucune primitive de corruption mémoire. L'attaque fonctionne sur tout système Insyde H2O où l'attaquant peut écrire dans la NVRAM, ce qui est le comportement par défaut sur un firmware non corrigé.
🎯 Attaque (Partie 1 - Contournement de Secure Boot)
Ce qui suit décrit l'attaque de bout en bout pour la phase initiale de contournement de Secure Boot, en supposant un attaquant privilégié avec un accès au niveau de l'OS :
- Générer un certificat personnalisé : L'attaquant génère une paire de clés et encapsule le certificat public au format EFI_SIGNATURE_LIST.
- Définir les variables NVRAM : À l'aide de l'outil SFCD depuis une session Administrateur Windows, l'attaquant crée les variables non volatiles SecureFlashCertData (contenant le certificat personnalisé) et SecureFlashSetupMode (définie à 1).
- Signer une charge utile : L'attaquant signe toute application ou pilote UEFI avec sa clé privée personnalisée.
- Enregistrer la charge utile : La charge utile signée est enregistrée comme pilote UEFI via le mécanisme d'option de démarrage DriverXXXX, ou placée comme entrée de démarrage dans le gestionnaire de démarrage UEFI.
- Redémarrer : Au prochain démarrage, SecurityStubDxe lit les variables NVRAM masquées, fait confiance au certificat de l'attaquant, et autorise l'exécution de la charge utile signée quel que soit l'état de Secure Boot.
🔺 Escalade (Partie 2 - Prise de contrôle du volume DXE)
Le contournement de Secure Boot obtenu dans la Partie 1 ouvre la porte à une seconde phase nettement plus impactante : la prise de contrôle complète du volume DXE, obtenue en détournant le processus de mise à jour du firmware Insyde lui-même.
Le sous-système de mise à jour du firmware dans Insyde H2O fonctionne comme suit : le programme de mise à jour de l'OS place une capsule de firmware et l'application de mise à jour signée (isflash.bin) sur la partition système EFI, puis définit un indicateur SecureFlashTrigger=1 dans la variable NVRAM SecureFlashInfo. Au prochain démarrage, le firmware détecte le déclencheur, désactive les protections en écriture de la flash pendant PEI, et finit par appeler LoadImage sur isflash.bin après l'avoir vérifié par rapport au certificat Insyde, le même mécanisme de certificat que CVE-2025-4275 permet à un attaquant de remplacer.
Trois étapes techniques supplémentaires sont nécessaires pour passer du contournement de Secure Boot à la prise de contrôle du DXE :
- Contournement de la suppression de SecureFlashCertData : SecureFlashDxe tente de supprimer la variable de certificat avant d'appeler LoadImage, en utilisant un appel SetVariable nu qui ne peut pas supprimer les variables spéciales Insyde Authenticated Write (AW). L'attaquant redéfinit le certificat comme variable spéciale attribuée AW pour survivre à cette tentative de suppression.
- Déverrouillage d'InsydeVariableLock : VariableRuntimeDxe définit un indicateur global (InsydeVariableLock) qui empêche la création de variables AW après le démarrage de BDS. En enregistrant un pilote UEFI via DriverXXXX (qui s'exécute avant que ce verrou ne soit engagé), l'attaquant localise l'indicateur en mémoire en analysant la chaîne de hooks BdsArchProtocol->Entry et le fait basculer de 1 à 0.
- Définition de SecureFlashInfo : La variable SecureFlashInfo est normalement protégée par VariableLockProtocol, mais ce verrou n'est engagé qu'à ReadyToBoot. Un pilote enregistré via DriverXXXX s'exécute avant cet événement et peut librement définir SecureFlashTrigger=1 pour initier le flux de mise à jour du firmware.
Une fois les trois conditions remplies, le firmware redémarre en mode mise à jour, charge l'isflash.bin personnalisé de l'attaquant (signé avec le certificat de l'attaquant, désormais de confiance en raison de la variable SecureFlashCertData masquée), et l'exécute avec la flash SPI non protégée. Depuis cette position, l'attaquant peut écrire du contenu arbitraire dans le volume DXE, installer des pilotes persistants ou modifier des composants du firmware de manière à survivre à une réinstallation de l'OS et à la plupart des contrôles de sécurité.
🩹 Correctif (Partie 3 - Analyse du patch)
Insyde a publié un correctif dans le cadre du cycle de patchs du 10 juin 2025. Le correctif a été analysé en comparant deux mises à jour BIOS Dell consécutives (une avant patch, une après patch) à l'aide de rapports générés par UEFITool et d'un diff binaire via Diaphora.
Les changements étaient concentrés dans trois pilotes :
- BdsDxe : Remplacement de l'appel nu gRT->SetVariable (qui ne pouvait pas supprimer les variables spéciales attribuées AW) par un appel LibSetSecureVariable qui utilise la communication SMM et peut supprimer de telles variables.
- SecureFlashDxe : Application du même remplacement par LibSetSecureVariable, ajout de la suppression explicite de SecureFlashSetupMode et SecureFlashCertData au point d'entrée du pilote, et enregistrement d'une VariablePolicy pour les deux variables afin de bloquer leur création depuis du code au niveau de l'OS.
- SecurityStubDxe : Correctif mineur sans rapport sur le gestionnaire d'événement `ExitBootServices ; le chemin de vulnérabilité principal reste structurellement inchangé.
Le correctif est efficace sous l'hypothèse qu'un attaquant ne peut pas contourner VariablePolicy ou LibSetSecureVariable. Cependant, l'implémentation par défaut de VariablePolicy dans EDK2 utilise un indicateur global en interne, structurellement similaire à InsydeVariableLock vaincu dans la Partie 2. L'édition physique de la NVRAM via du matériel de programmation SPI contournerait également entièrement le correctif, bien que les attaques physiques soient conventionnellement hors périmètre pour les modèles de menace de Secure Boot.
La remédiation recommandée par le chercheur, supprimer entièrement la NVRAM du mécanisme de relais de certificat entre BdsDxe et SecurityStubDxe, a été tentée par Insyde mais a causé des régressions et a été reportée à un futur cycle d'ingénierie.
📦 Vendeurs affectés
Tout vendeur livrant un firmware basé sur Insyde H2O construit avant le 10 juin 2025 est potentiellement affecté. Statut confirmé au moment de la divulgation :
| Vendeur | Statut |
|---|---|
| Dell | Corrigé - mises à jour BIOS publiées peu après la fin de l'embargo |
| Lenovo | Vulnérable - correctifs annoncés, livraison à partir du 2025-07-30 |
| Framework | Vulnérable - aucune estimation de livraison fournie au moment de la divulgation |
| Acer | Aucun avis ni correctif publié au moment de la divulgation |
| Fujitsu | Aucun avis ni correctif publié au moment de la divulgation |
| HP | Aucun avis ni correctif publié au moment de la divulgation |
| Huawei | Vendeur de l'appareil de test original - statut du correctif inconnu |
🤝 Recherche et collaboration
Vous travaillez sur quelque chose de similaire ? Vous faites de la recherche sur UEFI, la sécurité du noyau, l'exploitation, ou un autre sujet de sécurité intéressant ? Si vous avez besoin d'aide pour développer un exploit, explorer une technique, ou simplement échanger des idées, n'hésitez pas à me contacter. Je suis toujours ouvert à discuter de recherche, aider quand je peux, et collaborer sur des projets intéressants. N'hésitez pas à me contacter sur LinkedIn.