Une signature valide ne veut plus dire code sûr
Secure Boot a fait exactement ce pour quoi il a été conçu, et c'était là le problème. Le 14 juillet, la société de sécurité ESET a publié une recherche, menée par Martin Smolar, montrant onze chargeurs de démarrage signés par Microsoft, tous en version 0.9 ou inférieure, qu'une machine exécute volontiers parce que la signature est authentique. Le code derrière cette signature a une décennie et il est défaillant, mais Secure Boot vérifie le signataire, pas la sûreté de ce qui a été signé.
Le résultat est un attaquant capable d'exécuter du code non vérifié au démarrage sur presque tout ordinateur UEFI. ESET a signalé la découverte au centre de coordination CERT/CC en février, et Microsoft a ajouté les onze fichiers à sa liste de révocation le 9 juin. L'écart entre une signature approuvée et un code digne de confiance est toute l'histoire, et le correctif seul ne le comble pas.
Comment fonctionne le contournement
L'attaquant ne force rien ; il fournit quelque chose de déjà approuvé. La plupart des systèmes UEFI portent le certificat tiers de Microsoft, le Microsoft Corporation UEFI CA 2011, dans leur liste de signataires autorisés. Un attaquant copie l'un des anciens chargeurs signés sur la partition système EFI, la petite zone de démarrage du disque, et le micrologiciel l'accepte parce que la signature remonte à ce certificat approuvé. Aucun droit d'administrateur n'est requis, seulement la possibilité d'écrire ce fichier.
À partir de là, trois anciennes failles font le travail. Les chargeurs font confiance à du code GRUB 2 obsolète portant une faille de 2015 qui exécute des modules non vérifiés ; les versions inférieures à 0.9 n'ont pas la liste de révocation qui bloquerait les certificats reconnus comme malveillants ; et celles antérieures à la 15.3 ignorent SBAT, le mécanisme plus récent censé retirer les binaires vulnérables. Enregistrée sous CVE-2026-8863 et CVE-2026-10797, la chaîne s'achève avec le code de l'attaquant qui s'exécute avant le chargement du système d'exploitation, l'endroit idéal pour se cacher.
Pourquoi le correctif est la partie facile
Une révocation ne protège que la machine qui l'a réellement reçue. Le correctif de Microsoft du 9 juin ajoute les onze fichiers à dbx, la liste de blocage du micrologiciel, et sur les flottes Windows gérées cette mise à jour passe par les canaux normaux. Le hic, c'est que beaucoup d'organisations retiennent volontairement les changements de la liste du micrologiciel, car une entrée dbx erronée peut laisser un appareil incapable de démarrer, et ce risque est plus élevé sur du matériel ancien ou en double amorçage. La révocation existe ; savoir si elle a atteint vos machines est une autre question.
Le problème de fond est le comptage. Le registre public de revue des chargeurs n'a commencé qu'en 2017, et il n'existe pas de liste comparable de ce qui a été signé avant, si bien que personne ne peut affirmer avec certitude combien d'anciens chargeurs encore approuvés circulent. Onze est le nombre qu'ESET a pu nommer, pas le nombre qui existe. Un contrôle qui dépend de connaître chaque signataire approuvé est faible précisément là où l'inventaire s'arrête.
Ce qu'il faut vraiment vérifier cette semaine
Traitez cela comme une tâche d'hygiène des révocations, pas comme un simple correctif. Confirmez que la mise à jour dbx du 9 juin s'est réellement appliquée sur tout le parc au lieu de le supposer ; ESET renvoie à des outils d'audit et à des vérifications PowerShell qui indiquent l'état de révocation actuel. Étendez le contrôle au-delà de Windows, car les serveurs Linux et les équipements reçoivent le même correctif via le Linux Vendor Firmware Service, et les portables en double amorçage sont l'angle mort classique.
Pour les opérateurs européens, le cadre est désormais autant réglementaire que technique. Sous NIS2, l'intégrité de la chaîne de démarrage relève des mesures de sécurité qu'une entité essentielle doit pouvoir démontrer, et un bootkit dans le micrologiciel est exactement le type de persistance sur lequel un superviseur interrogera après un incident. L'action du dirigeant est simple à énoncer et facile à esquiver : vérifiez ce à quoi votre micrologiciel fait encore confiance, et prouvez que le blocage est arrivé.
À lire ensuite: 570 correctifs Windows en un jour, deux déjà exploités | Une faille Cisco de 18 ans, délai de 3 jours
