Microsoft a révoqué onze anciens chargeurs de démarrage toujours approuvés par Secure Boot malgré des vulnérabilités connues. Ils pouvaient permettre à un attaquant de contourner la protection et d’exécuter du code avant Windows.

Microsoft corrige une faille Secure Boot passée inaperçue pendant plus de dix ans. © pixadot.studio / Shutterstock
Microsoft corrige une faille Secure Boot passée inaperçue pendant plus de dix ans. © pixadot.studio / Shutterstock

Pendant plus de dix ans, Secure Boot a continué de faire confiance à plusieurs chargeurs UEFI vulnérables signés par Microsoft. Identifiés par les chercheurs d’ESET, ils pouvaient être introduits sur un PC pour contourner la protection et exécuter du code malveillant avant le lancement de Windows. Microsoft les a révoqués en juin, un correctif repris dans son Patch Tuesday record de juillet, qui corrige au total 622 failles.

Des shim vulnérables toujours reconnus comme fiables

Pour rappel, Secure Boot contrôle les logiciels lancés avant le système d’exploitation. Au démarrage, le firmware UEFI vérifie que chaque application qu’il charge est signée par une autorité approuvée et qu’elle ne figure pas dans la liste des éléments interdits. Dans le cas contraire, son exécution est bloquée.

Cette chaîne de confiance ne concerne pas uniquement Windows. La plupart des PC font aussi confiance à un certificat de Microsoft destiné aux logiciels UEFI tiers. Celui-ci sert notamment à signer de petits chargeurs intermédiaires appelés shim, utilisés par exemple par Linux pour valider le reste de la chaîne de démarrage, généralement GRUB 2 puis le noyau.

Or, ESET a mis le doigt sur onze shim vulnérables datant de 2015 ou d’avant, toujours reconnus comme fiables par Secure Boot. Un attaquant disposant déjà des droits nécessaires pouvait ainsi en déposer lui-même une copie dans la partition de démarrage d’un PC Windows, puis profiter de leur signature Microsoft pour contourner la protection et déployer un bootkit avant le lancement du système, un type de malware particulièrement difficile à détecter.

Une révocation tardive et peut-être encore incomplète

ESET a signalé ses découvertes au CERT/CC en février 2026. Microsoft a depuis ajouté les empreintes des onze fichiers concernés à la DBX, la base de révocation qui recense les certificats et applications UEFI que Secure Boot doit refuser d’exécuter.

Cette nouvelle liste noire a été distribuée avec la mise à jour KB5094126 du Patch Tuesday de juin, avant d’être reprise dans KB5101650 en juillet. Les mises à jour de Windows étant cumulatives, l’installation du dernier Patch Tuesday suffit donc à appliquer le correctif.

À noter que cette révocation était indispensable malgré l’expiration, le 27 juin dernier, du certificat Microsoft utilisé pour signer ces chargeurs. Secure Boot ne tient pas compte de sa date d’expiration : les fichiers déjà signés seraient restés fiables tant qu’ils n’étaient pas explicitement bloqués dans la DBX.

ESET a par ailleurs prévenu que ces onze fichiers ne représentent peut-être qu’une partie du problème. Les shim signés avant 2017 n’ont pas tous été publiquement catalogués, ce qui empêche de savoir combien d’anciens chargeurs vulnérables pourraient encore être considérés comme fiables.

Windows 11
  • Refonte graphique de l'interface réussie
  • Snap amélioré
  • Groupes d'ancrage efficaces
8 / 10
Foire aux questionsContenu généré par l’IA
À quoi sert Secure Boot dans une machine UEFI, et comment fonctionne sa “chaîne de confiance” ?

Secure Boot est un mécanisme d’UEFI qui n’autorise le chargement, au démarrage, que de composants considérés comme fiables (bootloaders, gestionnaires de démarrage, etc.). Cette confiance repose sur des signatures numériques : l’UEFI vérifie que chaque binaire est signé par une autorité approuvée et qu’il n’est pas explicitement blacklisté. Si la signature n’est pas reconnue ou si le composant est révoqué, l’exécution est bloquée avant même que l’OS ne démarre. L’objectif est d’empêcher l’injection de code très tôt dans le boot, là où l’antivirus et la plupart des protections Windows ne sont pas encore actifs.

Qu’est-ce qu’un “shim” dans le démarrage Secure Boot, et pourquoi est-il critique pour Linux (et parfois exploitable sur Windows) ?

Un shim est un petit chargeur intermédiaire, souvent utilisé par Linux, qui sert de “pont” entre Secure Boot et le reste de la chaîne de démarrage (par exemple GRUB2 puis le noyau). Il est typiquement signé avec un certificat largement reconnu par les firmwares PC, ce qui permet de démarrer même quand la distribution ne dispose pas d’une signature directement approuvée par l’UEFI. Le problème, c’est qu’un shim vulnérable et toujours accepté devient un point d’entrée : sa signature “valide” peut suffire à faire exécuter un code détourné au tout début du boot. Avec des droits suffisants, un attaquant peut déposer ce shim sur la partition de démarrage et s’en servir pour amorcer une chaîne de chargement malveillante.

Qu’est-ce que la DBX (base de révocation Secure Boot) et pourquoi la date d’expiration d’un certificat ne suffit pas à bloquer un ancien bootloader ?

La DBX est la liste de révocation utilisée par Secure Boot pour refuser certains certificats ou binaires UEFI identifiés comme dangereux, même s’ils sont correctement signés. En pratique, ajouter une empreinte (hash) ou un certificat dans la DBX revient à “retirer la confiance” à des composants précis, au niveau firmware. La date d’expiration d’un certificat ne garantit pas le blocage, car Secure Boot peut continuer à accepter des binaires déjà signés tant qu’ils ne sont pas explicitement révoqués. C’est pour ça qu’une mise à jour Windows/firmware qui met à jour la DBX est cruciale : elle neutralise des bootloaders historiques qui resteraient autrement utilisables pour contourner la protection.