ESET : 11 shims UEFI signés Microsoft bypassent Secure Boot

Onze shims UEFI jamais révoqués ouvrent une brèche dans Secure Boot

Le 14 juillet 2026, le chercheur en sécurité Martin Smolár de la société ESET a publié une analyse technique approfondie sur le blog WeLiveSecurity, révélant l'existence de 11 shims UEFI Linux légitimement signés par Microsoft et exploitables pour contourner la protection Secure Boot sur la quasi-totalité des systèmes modernes. Ces résultats ont également conduit à la publication d'un avis de sécurité CERT/CC référencé VU#616257. La divulgation intervient après que Microsoft a pris les mesures correctives nécessaires en révoquant les binaires vulnérables lors du Patch Tuesday du 9 juin 2026, ce qui illustre un processus de divulgation coordonnée rigoureux entre ESET et Microsoft.

Pour comprendre l'enjeu, il faut rappeler le rôle de Secure Boot dans l'architecture de sécurité des PC modernes. Secure Boot est une fonctionnalité du firmware UEFI qui vérifie, lors du démarrage du système, que chaque composant chargé est signé numériquement par une autorité de confiance. Microsoft est l'une des autorités de signature centrales pour l'écosystème PC : sa clé "Microsoft UEFI CA 2011" est présente dans la base de données de confiance de la quasi-totalité des firmwares UEFI des PC vendus dans le monde depuis 2012. Tout composant de démarrage portant la signature de Microsoft est considéré comme de confiance et peut s'exécuter même si Secure Boot est activé.

Dans l'écosystème Linux, un composant particulier joue un rôle clé : le shim. Le shim est un petit chargeur d'amorçage intermédiaire, lui-même signé par Microsoft, qui permet aux distributions Linux de démarrer sur des machines avec Secure Boot activé. Le shim vérifie ensuite la signature du chargeur GRUB, qui à son tour vérifie le noyau Linux. Cette chaîne de confiance est le mécanisme standard permettant aux distributions comme Ubuntu, Fedora ou Debian de coexister avec Secure Boot sur des machines dont Microsoft contrôle les certificats racines UEFI.

La découverte de Smolár porte sur 11 versions anciennes de ce shim — toutes en version 0.9 ou antérieure — qui avaient été légitimement signées par Microsoft à l'époque de leur distribution, mais qui n'avaient jamais été révoquées malgré le passage à des versions plus récentes et sécurisées. Un attaquant disposant d'un accès local suffisant pour modifier la configuration de démarrage EFI — ou opérant depuis un système déjà compromis avec des droits d'administration — peut utiliser l'un de ces vieux shims pour injecter du code non signé lors du démarrage, contournant intégralement la vérification Secure Boot. Cette capacité est précisément ce dont ont besoin les opérateurs de bootkits UEFI, une catégorie de malware particulièrement redoutable car elle s'exécute avant le chargement du système d'exploitation et persiste même après la réinstallation complète de l'OS.

Le lien avec les attaques de type bootkit UEFI est direct et préoccupant. Le bootkit BlackLotus, apparu fin 2022 et documenté par ESET en 2023, exploitait déjà une technique similaire en abusant de chargeurs de démarrage Windows non révoqués pour contourner Secure Boot et désactiver des protections comme Microsoft Defender. L'existence de ces 11 shims Linux non révoqués offre un vecteur équivalent pour les systèmes Linux et les environnements dual-boot Windows/Linux. Des groupes APT et des opérateurs de ransomware sophistiqués ont démontré leur intérêt marqué pour les techniques de persistance au niveau firmware, qui offrent une résistance maximale aux mesures de remédiation classiques.

ESET précise que la divulgation complète des détails techniques a été retardée jusqu'à ce que Microsoft intègre les révocations dans la UEFI Revocation List (base de données dbx) lors du Patch Tuesday du 9 juin 2026. Les systèmes Windows ayant appliqué cette mise à jour ne peuvent plus charger ces 11 shims vulnérables même si un attaquant tente de les utiliser. Cependant, la mise à jour de la liste de révocation UEFI n'est pas automatique sur tous les systèmes et nécessite une attention particulière des équipes de sécurité, notamment sur les parcs de machines industrielles, les serveurs bare-metal avec des cycles de mise à jour différés, et les systèmes Linux qui ne bénéficient pas de Windows Update.

ESET souligne un problème structurel plus profond dans l'écosystème UEFI Secure Boot. Personne ne sait avec certitude combien de shims ou de bootloaders signés restent potentiellement non révoqués. La base de données des binaires signés par Microsoft est vaste et ancienne, et le processus de révocation — qui nécessite la publication d'une nouvelle UEFI Revocation List et sa distribution via Windows Update — est lent et ne couvre pas les systèmes Linux purs, les machines air-gapped ou les équipements industriels avec des cycles de mise à jour très longs. L'intitulé de l'article de recherche ESET résume le problème : "No one knows how many old shims can still bypass UEFI Secure Boot".

Les administrateurs système doivent s'assurer que la mise à jour de la UEFI Revocation List de juin 2026 est bien appliquée sur l'ensemble du parc informatique. Cette vérification est particulièrement critique sur les serveurs bare-metal, les postes de travail de développement, les systèmes dual-boot Windows/Linux et tout équipement utilisant un chargeur d'amorçage Linux tiers. Sur les systèmes purement Linux, l'outil fwupd ou les outils de firmware du fabricant permettent de mettre à jour la base dbx indépendamment de Windows Update.

Les implications structurelles pour la sécurité du firmware

La découverte des 11 shims vulnérables illustre une tension fondamentale dans la conception de Secure Boot. Le mécanisme repose sur la confiance accordée aux autorités de signature, mais la révocation de binaires déjà signés et distribués est un processus complexe, lent et imparfait. La UEFI Revocation List (dbx) doit être mise à jour sur chaque machine individuellement, ce processus dépendant de la coopération des fabricants de firmware, des éditeurs d'OS, des distributeurs Linux et des utilisateurs finaux. Sur des cycles de vie de plusieurs années, de nombreuses machines ne reçoivent jamais ces mises à jour critiques de firmware UEFI.

Le précédent BlackLotus avait déjà révélé que des bootloaders Windows antérieurs à 2012 pouvaient contourner Secure Boot, forçant Microsoft à publier des mises à jour de révocation en mai 2023. La découverte ESET de juillet 2026 démontre que le problème n'est pas résolu et s'étend à l'écosystème Linux. Chaque fois qu'un composant de démarrage est signé et distribué, il entre dans un cycle de vie pouvant durer des décennies, et sa révocation n'est jamais garantie. Des chercheurs anticipent que d'autres binaires signés vulnérables pourraient être découverts dans les années à venir, affectant potentiellement d'autres systèmes d'exploitation ou d'autres fournisseurs de matériel.

Pour les entreprises, l'enjeu dépasse la simple application d'un correctif. Les bootkits UEFI représentent la forme la plus persistante de compromission connue : ils s'installent dans la partition ESP (EFI System Partition), s'exécutent avant le chargement de l'OS et de tout outil de sécurité, et survivent aux réinstallations complètes du système d'exploitation, aux changements de disques durs et résistent à la grande majorité des outils de détection basés sur l'OS. La seule remédiation fiable est souvent le reflash complet du firmware UEFI ou le remplacement physique de la machine. Cette réalité impose aux équipes de sécurité de traiter les alertes de détection de modifications du firmware comme des incidents de priorité maximale.

Sur le plan des recommandations, au-delà de l'application de la UEFI Revocation List de juin 2026, les organisations devraient activer les fonctionnalités de mesure d'intégrité du firmware comme TPM 2.0 avec Microsoft Pluton, déployer des solutions de détection des modifications UEFI via des outils EDR capables de surveiller les modifications de la partition ESP, et établir une base de référence cryptographique des firmwares pour détecter toute modification non autorisée lors des audits périodiques.

Ce qu'il faut retenir

• Vérifier que le Patch Tuesday de juin 2026 (UEFI Revocation List dbx) est bien appliqué sur l'ensemble du parc, en priorité sur les serveurs bare-metal et les systèmes Linux ou dual-boot.
• Les bootkits UEFI persistent après réinstallation de l'OS : tout système suspect doit faire l'objet d'une analyse forensique du firmware avant toute tentative de remédiation.
• Le problème structurel des binaires signés non révoqués impose une surveillance continue des publications CERT/CC et des mises à jour de la base dbx dans le cadre du programme de gestion des vulnérabilités.