Recherche sur CVE-2025-3052, une vulnérabilité du firmware Insyde qui expose une primitive d'écriture arbitraire capable de modifier des pointeurs critiques pour la sécurité.
Ce dépôt centralise le matériel de recherche lié à CVE-2025-3052, une vulnérabilité de corruption mémoire dans un module UEFI signé avec le certificat tiers de Microsoft, qui permet à un attaquant de corrompre des structures de firmware critiques pour la sécurité, de neutraliser l'application de Secure Boot et d'exécuter du code non signé arbitraire avant le chargement du système d'exploitation. Il comprend une analyse technique de la cause racine et de la technique d'exploitation, des binaires vulnérables réels et éducatifs, ainsi qu'une documentation de support destinée à aider les chercheurs à comprendre, reproduire et expérimenter cette classe de vulnérabilité.
CVE-2025-3052 a été découverte et divulguée de manière responsable par l'équipe de recherche de Binarly. Références officielles et communautaires :
Ce dépôt inclut deux binaires vulnérables, fournis avec des objectifs de recherche et d'apprentissage différents.
Ce binaire représente la vulnérabilité telle qu'elle existait dans la nature.
CVE-2025-3052 est une vulnérabilité de contournement de Secure Boot affectant les systèmes UEFI, causée par la gestion non sécurisée de données récupérées depuis une variable NVRAM au sein d'une application UEFI signée. La vulnérabilité permet à un attaquant de corrompre des structures de firmware critiques pour la sécurité pendant le processus de démarrage, brisant effectivement la chaîne de confiance UEFI et permettant l'exécution de code non signé avant le chargement du système d'exploitation.
Ce qui rend cette vulnérabilité particulièrement impactante n'est pas seulement la nature du bug lui-même, une primitive de corruption mémoire, mais le contexte dans lequel il existe : un module UEFI signé avec le certificat UEFI tiers de Microsoft, approuvé par défaut sur la grande majorité des systèmes modernes. Par conséquent, l'exploitation se produit à l'un des stades d'exécution les plus précoces et les plus privilégiés de la plateforme, avant les contrôles de sécurité au niveau du système d'exploitation.
Secure Boot est une fonctionnalité de sécurité essentielle d'UEFI conçue pour faire respecter la chaîne de confiance de la plateforme, du firmware au système d'exploitation. Son objectif principal est d'empêcher l'exécution de composants de démarrage non autorisés ou malveillants, tels que les bootkits, pendant le processus de démarrage.
À un niveau élevé, Secure Boot fonctionne en validant cryptographiquement les exécutables UEFI avant de les autoriser à s'exécuter. Cette validation est effectuée à l'aide de deux bases de données maintenues par le firmware :
Une application UEFI est autorisée à s'exécuter si :
Par défaut, la plupart des systèmes sont livrés avec les certificats suivants approuvés dans db :
Les modules vulnérables associés à CVE-2025-3052 ont été signés à l'aide du certificat Microsoft Corporation UEFI CA 2011. Comme ce certificat est largement approuvé par les fournisseurs et les plateformes, toute application signée l'utilisant peut s'exécuter sur la plupart des systèmes UEFI sans interaction de l'utilisateur. Cette confiance étendue amplifie considérablement l'impact d'une vulnérabilité au sein d'un tel module, car elle contourne effectivement les garanties de protection prévues par Secure Boot.
Le module UEFI vulnérable a été initialement découvert lors d'une analyse à grande échelle de binaires UEFI téléversés sur des dépôts publics de malwares, notamment VirusTotal. Bien que la première soumission publique du module ait eu lieu en novembre 2024, l'inspection de sa signature Authenticode a révélé qu'il avait été signé dès octobre 2022, indiquant que le binaire pouvait circuler depuis un temps considérable avant sa détection.
Le nom de fichier original observé lors de l'analyse était Dtbios-efi64-71.22.efi. L'examen des chaînes intégrées, des métadonnées de certificat et du comportement du fichier suggérait fortement que le module avait été développé par DT Research, Inc, un fournisseur spécialisé dans les appareils informatiques mobiles robustes.
Une ingénierie inverse plus poussée a révélé que le module est un utilitaire de flashage de BIOS, conçu pour lire une image de firmware depuis le disque et l'écrire dans la ROM du système. Bien qu'initialement destiné au matériel DT Research, le module n'est pas restreint à une plateforme spécifique et peut s'exécuter sur tout système qui approuve le certificat UEFI tiers de Microsoft.
Un indice critique lors de la reconnaissance était la présence de la variable NVRAM IhisiParamBuffer. Cette variable est étroitement associée aux implémentations de firmware basées sur Insyde et avait déjà été impliquée dans d'autres vulnérabilités divulguées par Binarly (par exemple, BRLY-2022-023 et BRLY-2023-005). Sa présence suggérait immédiatement une classe potentielle de problèmes liés à la NVRAM.
La cause racine de CVE-2025-3052 réside dans l'utilisation non sécurisée de données lues depuis une variable NVRAM sans validation. Plus précisément :
Par conséquent, un attaquant capable de contrôler la variable IhisiParamBuffer acquiert la capacité d'influencer l'emplacement en mémoire où ces écritures se produisent. Bien que la primitive d'écriture soit quelque peu contrainte, permettant généralement des écritures de zéro ou de petites constantes à une adresse arbitraire, elle reste suffisamment puissante pour corrompre un état critique du firmware.
Dans la preuve de concept de Binarly, l'attaque cible la variable globale gSecurity2, qui contient un pointeur vers le Security2 Architectural Protocol (pour une explication détaillée de cette technique d'exploitation spécifique, consultez le dépôt suivant « TheMalwareGuardian: Exploitation Technique SecureBoot Bypass gSecurity2 Corruption »). Ce protocole est consulté par le service LoadImage pour faire respecter la politique Secure Boot, ce qui signifie qu'écraser gSecurity2 avec un pointeur nul désactive effectivement les vérifications Secure Boot à l'exécution. Fait crucial, ce contournement est transparent pour le système d'exploitation : une fois démarré, Secure Boot apparaît toujours activé au niveau du système d'exploitation, même s'il a été entièrement neutralisé au niveau du firmware.
Une nuance importante est que sur les plateformes basées sur Insyde, la variable IhisiParamBuffer est généralement verrouillée en lecture seule, ce qui empêche effectivement l'exploitation sur ces systèmes sans une vulnérabilité supplémentaire. Ironiquement, cela signifie que le fournisseur dont l'IBV a introduit le modèle de variable vulnérable en premier lieu est parmi les moins exposés, tandis que toutes les autres plateformes restent à risque. Dans les cas où la variable est verrouillée, un contournement tel que BRLY-2023-005 peut être chaîné pour obtenir un accès en écriture à la variable avant de procéder à l'exploitation. Sur les systèmes où la variable est directement accessible en écriture, l'attaque est simple et hautement fiable.
Ce qui suit décrit l'attaque de bout en bout exploitant CVE-2025-3052, en supposant un attaquant privilégié disposant d'un accès au niveau du système d'exploitation :
Microsoft a déterminé que 14 modules UEFI différents étaient affectés et a atténué le problème en ajoutant leurs hachages à la dbx de Secure Boot.
| Nom du module | Hachage Authenticode SHA-256 |
|---|---|
| BiosFlashShell-efi64-80.02.efi | C54A4060B3A76FA045B7B60EEAEBC8389780376BA3EF1F63D417BA1B5528E95 |
| BiosFlashShell-efi64-81.02.efi | CBFAA286144EB2D165A6B17245BAD4F73058436C7292BE56DC6EBA29A369ADDF |
| Dtbios-efi64-70.17.efi | 9D7E7174C281C6526B44C632BAA8C3320ADDD0C77DC90778CC14893882D74618 |
| Dtbios-efi64-70.18.efi | 9B1F35052CFC5FB06DABE5E8F7B747F081DA28D722DB59ADE253B9E38A7A3C76 |
| Dtbios-efi64-70.19.efi | E3CE55E584371D3F2FBCA2241EF0711FF80876EBF71BAB07D8ECEE645A40DCFC |
| Dtbios-efi64-70.20.efi | EE093913ABBD34CB8B5EA31375179A8B55A298353C03AFE5055AA4E8E3F705EF |
| Dtbios-efi64-70.21.efi | B4E1880425F7857B741B921D04FD9276130927CF90A427C454B970E7A2F442F9 |
| Dtbios-efi64-70.22.efi | CDA0B4A59390B36E1B654850428CBB5B4C7B5E4349E87ACDE97FB543736FF1D4 |
| Dtbios-efi64-71.17.efi | C87EFD057497F90321D62A69B311912B8EF8A045FE9C5E6BD5C8C1A4E6F39629 |
| Dtbios-efi64-71.18.efi | 9E19DD645235341A555D6AC0665591453AE13918ECD37DF22DFBEE91EAA9A2DA |
| Dtbios-efi64-71.19.efi | 63F67824FDA998798964FF33B87441857DA92F3A8EE3E04166EEC3156E4E6B82 |
| Dtbios-efi64-71.20.efi | 0BC4F078388D41AB039F87AE84CF8D39302CCBDD70C4ADEE02263EBF6A2DD328 |
| Dtbios-efi64-71.21.efi | E2AEC271B9596A461EB6D54DB81785E4E4C615CFDA5F4504BCC0A329248A4D36 |
| Dtbios-efi64-71.22.efi | 6B4328EBCBE46ED9118FF2D4472DE329D70BA83016DF7A6F50F8AF92342160A1 |
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.
