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.
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.
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 :
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.
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 :
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.
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 :
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.
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 :
