CVE-2025-3052 — Mis à jour !
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é.
🐞 CVE-2025-3052 : Corruption mémoire d'IhisiParamBuffer
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é.
📑 Table des matières
- Découverte originale et références officielles
- Binaires vulnérables (réels / éducatifs)
- Aperçu de la vulnérabilité (analyse, exploitation, PoC)
🧠 Découverte originale et références officielles
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 :
- Blog de recherche Binarly (10 juin 2025)
- Collection de références communautaires
🐜 Binaires vulnérables
Ce dépôt inclut deux binaires vulnérables, fournis avec des objectifs de recherche et d'apprentissage différents.
🧨 Binaire vulnérable réel
Ce binaire représente la vulnérabilité telle qu'elle existait dans la nature.
- Application UEFI vulnérable originale affectée par CVE-2025-3052.
- Destiné à l'analyse réelle et à l'ingénierie inverse.
- Signé avec le certificat UEFI tiers de Microsoft.
- Extrait de dépôts publics de malwares :
🎓 Binaire vulnérable éducatif
- Code source entièrement compilable d'une application UEFI éducative simplifiée.
- Reproduit la même prémisse de vulnérabilité que le binaire réel.
- Conçu pour aider les débutants à :
- Progresser graduellement vers l'analyse du binaire original.
- Éviter l'ingénierie inverse lourde aux premiers stades.
- Comprendre la mécanique de la vulnérabilité.
🧪 Aperçu de la vulnérabilité (analyse, exploitation, PoC)
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 et certificats Microsoft
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 :
- db : contient les hachages Authenticode de confiance et les certificats racines de confiance.
- dbx : contient les hachages et certificats révoqués ou explicitement non approuvés.
Une application UEFI est autorisée à s'exécuter si :
- Son hachage Authenticode correspond à une entrée dans db, ou
- Sa chaîne de certificats se valide jusqu'à un certificat racine de confiance présent dans db, et n'est pas présente dans dbx.
Par défaut, la plupart des systèmes sont livrés avec les certificats suivants approuvés dans db :
- Microsoft Corporation UEFI CA 2011 - utilisé pour signer des composants UEFI tiers, y compris le shim Linux.
- Microsoft Windows Production PCA 2011 - utilisé pour signer le chargeur d'amorçage Windows.
- Un ou plusieurs certificats appartenant à l'OEM.
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.
🔎 Découverte du module et reconnaissance
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.
💥 Découverte et exploitation de la vulnérabilité
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 :
- L'application UEFI récupère la valeur de la variable NVRAM IhisiParamBuffer.
- Cette valeur est traitée comme un pointeur de confiance et stockée dans une variable globale à l'adresse 0xf7a0.
- Le code effectue ensuite une opération d'écriture mémoire à global + 0x18, mettant cette adresse à zéro.
- D'autres opérations d'écriture suivent, toutes dérivées de la même valeur NVRAM contrôlée par l'attaquant.
- Aucune vérification des limites, validation de cohérence ou contrôle d'accès n'est appliqué à aucun moment.
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.
🎯 Déroulement de l'attaque
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 :
- Définir la variable NVRAM : L'attaquant définit la variable NVRAM IhisiParamBuffer depuis le système d'exploitation vers une adresse cible arbitraire, en la pointant vers gSecurity2.
- Enregistrer la charge utile : L'attaquant enregistre le module signé vulnérable dans le UEFI Boot Manager (ou remplace un chargeur de système d'exploitation existant par celui-ci), et enregistre en outre un second module non signé contenant la charge utile réelle.
- Redémarrer : Après le redémarrage du système, le firmware entre dans la phase Boot Device Selection (BDS) et commence à exécuter les entrées de démarrage enregistrées.
- Exécution : Le module signé vulnérable s'exécute en premier. Sa primitive d'écriture contrainte est utilisée pour écraser gSecurity2 avec null, désactivant l'application de Secure Boot. Les vérifications étant neutralisées, le firmware procède au chargement et à l'exécution du module de charge utile non signé, accordant à l'attaquant une exécution de code arbitraire à la fin de la phase DXE, avant que le système d'exploitation n'ait la moindre opportunité d'établir ses propres défenses.
📦 Modules affectés
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 |
🤝 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.