Deux nouvelles vulnérabilités découvertes dans Secure Boot mettent en lumière les failles potentielles des systèmes de sécurité, même ceux conçus par Microsoft. Les CVE-2025-3052 et CVE-2025-47827 vont poser des défis importants aux administrateurs systèmes dans les mois à venir car elles exploitent des outils légitimement signés par Microsoft pour désactiver les protections. C’est un peu comme si un serrurier gardait un double de vos clés pour accéder à votre domicile à son gré.
Fonctionnement de Secure Boot
Le concept de Secure Boot repose sur une technologie de sécurité définie dans la spécification UEFI, qui vérifie cryptographiquement la confiance de chaque composant de votre système au démarrage. Cela crée une chaîne de vérification remontant aux certificats racine, garantissant qu’aucun malware ne puisse s’installer avant que votre système d’exploitation ne soit opérationnel. En théorie, cela semble très solide, mais en pratique, des failles apparaissent.
Les vulnérabilités CVE-2025-3052 et CVE-2025-47827
CVE-2025-3052 exploite un utilitaire de flashage de firmware développé par DT Research, qui est signé avec le certificat “UEFI CA 2011” de Microsoft, celui-ci étant par défaut de confiance pour Secure Boot. Par conséquent, cet utilitaire peut désactiver Secure Boot sans que cela ne soulève d’alerte. Plus de 50 fabricants de matériel sont concernés, affectant tant les systèmes Windows que Linux.
D’autre part, CVE-2025-47827 cible un module kernel Linux développé par IGEL pour la gestion des volumes logiques. Ce module est également signé par Microsoft, utilisant le certificat “3rd Party UEFI CA”. Avec un accès physique de quelques minutes, un attaquant peut charger un bootloader malveillant, contournant totalement les protections.
Les risques associés
Ces vulnérabilités permettent aux attaquants de transformer Secure Boot en un accès non sécurisé, car les outils signés deviennent des passes VIP pour l’installation de bootkits persistants. Contrairement aux malwares traditionnels, un bootkit au niveau firmware peut survivre à un formatage, à une réinstallation du système d’exploitation, et même à des nettoyages approfondis. Il s’installe dans le firmware UEFI, se moquant de toute tentative d’éradiquer l’infection.
Réactions et mesures de Microsoft
Microsoft a mis en place un mécanisme appelé DBX (Database of Revoked Keys) pour révoquer les certificats compromis. Cependant, la lenteur de ce processus peut laisser des millions de machines vulnérables pendant des mois. Selon des experts, cette situation crée des opportunités pour les attaquants.
Impact sur les systèmes Linux
Pour les administrateurs Linux, ces failles soulèvent des problèmes critiques, car de nombreux environnements de production dépendent des certificats Microsoft pour faire fonctionner des distributions signées. Désactiver complètement cette chaîne de confiance n’est pas toujours une option viable dans des environnements mixtes Windows/Linux.
Actions recommandées
Microsoft a réagi lors du Patch Tuesday de juin 2025 en blacklistant les outils compromis. CVE-2025-3052 a reçu un correctif ajoutant 14 nouveaux hashs à la liste de révocation. Toutefois, ces mises à jour ne s’appliquent pas automatiquement à tous les systèmes, nécessitant souvent une intervention manuelle au niveau du BIOS/UEFI.
Pour CVE-2025-47827, IGEL a publié un avis de sécurité, mais la révocation du certificat Microsoft n’est pas encore universelle. Il est crucial de patcher immédiatement vos systèmes et de vérifier que tous les systèmes reçoivent bien les mises à jour.
Mesures de sécurité
- Patcher vos systèmes : Assurez-vous que les mises à jour DBX sont appliquées.
- Renforcer les paramètres BIOS/UEFI : Configurez des mots de passe, désactivez les périphériques de boot inutiles et sécurisez physiquement vos serveurs.
- Réévaluer la confiance envers les certificats Microsoft : Si possible, désactivez le certificat “3rd Party UEFI CA”.
- Investir dans le monitoring firmware : Utilisez des outils spécialisés pour détecter les vulnérabilités firmware et modifications inattendues.
Conclusion
Secure Boot reste fonctionnel, mais sa dépendance à des autorités comme Microsoft crée des points de défaillance critiques, surtout lorsque ces autorités tardent à révoquer des certificats compromis. La vigilance est de mise pour assurer la sécurité des systèmes en place.