Des chercheurs d’ESET ont identifié au moins 11 images de démarrage, dont une datant de 2013, encore signées par Microsoft malgré des failles connues. Ces shims, conçus pour étendre Secure Boot aux systèmes Linux, permettent de contourner la protection intégrée à l’UEFI. L’exposition concerne des machines sous Windows comme sous Linux, avec un risque de compromission persistante au niveau firmware.
Ce qui frappe dans cette affaire, ce n’est pas seulement l’existence de shims vulnérables, mais leur disponibilité durable et l’absence de révocation côté chaîne de confiance. Une faiblesse discrète, exploitable avec des techniques accessibles, peut suffire à faire sauter un mécanisme censé bloquer les infections avant même le chargement du système.
ESET relie 11 shims vulnérables à la chaîne Secure Boot
La découverte est attribuée à des chercheurs du laboratoire d’ESET, qui ont remonté la piste de plusieurs images de démarrage historiquement utilisées dans l’écosystème Secure Boot. Selon leurs constatations, 11 shims au total, dont au moins un exemplaire daté de 2013, étaient connus comme défectueux, mais restaient malgré tout signés par Microsoft. Dans un modèle de sécurité fondé sur la signature, le fait qu’un composant ancien et vulnérable conserve une signature de confiance revient à laisser une porte latérale ouverte, même si les versions récentes ont été corrigées.
Le terme shim désigne un petit chargeur intermédiaire introduit pour répondre à un problème pratique, permettre à Linux et à des outils de maintenance de démarrer sur des machines où Secure Boot impose une chaîne de signatures approuvées. Dans beaucoup de configurations, le firmware UEFI fait confiance à une clé ou à une base de certificats, puis valide un premier binaire signé. Le shim joue ce rôle, il est accepté par le firmware, puis il peut valider à son tour le chargeur suivant, par exemple GRUB ou un autre composant de démarrage.
Ce mécanisme, utile pour l’interopérabilité, crée aussi une surface d’attaque, la confiance accordée au shim devient un pivot. Si un shim ancien contient une vulnérabilité permettant de charger un binaire non autorisé, l’attaquant obtient un moyen de casser la chaîne. ESET insiste sur un point, ces shims oubliés n’étaient pas seulement archivés, ils restaient publiquement disponibles, donc récupérables par un tiers qui chercherait à les réutiliser sur une machine ciblée.
Le cur du problème décrit par les chercheurs tient moins à l’existence de bogues, fréquents dans l’histoire des logiciels, qu’à la gestion des révocations. Dans Secure Boot, la révocation sert à dire au firmware, ce binaire, même signé, ne doit plus être accepté. Sans cette étape, un composant compromis peut rester valide indéfiniment dans la pratique.
Éléments clés de cette section, ESET, 11 shims, 2013, signature Microsoft.
Pourquoi Secure Boot peut être contourné via des shims non révoqués
Secure Boot repose sur une idée simple, empêcher le chargement de code non approuvé au démarrage, en verrouillant la séquence d’exécution dès les premières étapes. Cette protection est ancrée dans l’UEFI de la carte mère, avant le système d’exploitation. Dans un scénario normal, le firmware valide cryptographiquement le premier composant, qui valide le suivant, et ainsi de suite. Tant que chaque maillon est intègre et que les éléments défaillants sont exclus via des listes de révocation, un malware a peu d’espace pour s’insérer.
Les shims ont été introduits pour concilier ce modèle strict avec la diversité du monde Linux. Sur de nombreuses machines, la base de confiance inclut des clés associées à Microsoft, ce qui a conduit à un schéma où un shim Linux est signé de manière à être accepté par le firmware. Ce shim, ensuite, peut appliquer des règles propres à la distribution ou à l’outil utilisé. Le design facilite le démarrage de systèmes alternatifs, mais il déplace aussi une partie du contrôle vers ce binaire intermédiaire, qui devient un point de passage obligé.
Le contournement décrit par ESET s’appuie sur un principe classique, réutiliser un composant ancien, signé, mais vulnérable. Si un attaquant parvient à installer un shim fautif sur la machine, il peut exploiter la faiblesse pour charger du code qui aurait dû être bloqué. Le texte source souligne que la technique est suffisamment simple pour être mise en uvre par des profils peu expérimentés, ce qui, dans une logique de menace, élargit le nombre d’acteurs capables de tenter une attaque.
La notion déterminante est la révocation. Quand une vulnérabilité est découverte dans un binaire signé, l’éditeur ou l’autorité responsable doit le placer dans une liste de blocage, souvent distribuée via des mises à jour firmware ou système. Ici, la faille organisationnelle pointe un défaut de suivi, des shims connus comme vulnérables n’auraient pas été révoqués, ce qui maintient leur acceptation par Secure Boot.
Ce type de situation est difficile à corriger rapidement, car la chaîne Secure Boot implique plusieurs acteurs, constructeurs, éditeurs, distributions, administrateurs systèmes. Plus le parc est vaste et hétérogène, plus le déploiement d’une révocation risque d’être lent, avec des contraintes de compatibilité. Bloquer un shim peut casser le démarrage de certaines configurations, ce qui explique pourquoi ces opérations sont souvent menées avec prudence, mais cette prudence peut se transformer en inertie si la gouvernance n’est pas rigoureuse.
Éléments clés de cette section, Secure Boot, UEFI, shim, révocation.
Une compromission UEFI persiste après réinstallation de Windows ou Linux
Le scénario le plus préoccupant évoqué par la source touche à la nature même des attaques firmware. Une fois que l’attaquant a réussi à subvertir la chaîne de confiance, il peut viser l’installation d’un code malveillant au niveau UEFI ou dans des composants qui s’exécutent très tôt. Dans ce cas, la compromission intervient avant le chargement de Windows ou de Linux, ce qui permet au malware d’observer, modifier ou détourner des éléments critiques, comme le chargeur, le noyau, ou des mécanismes de sécurité qui supposent un démarrage sain.
La persistance est l’un des marqueurs de ces attaques. Une infection firmware peut survivre à des opérations qui, pour beaucoup d’utilisateurs, représentent une remise à zéro, réinstallation complète du système, changement de disque dur, restauration d’une image. La source indique explicitement que le code malveillant peut persister même après réinstallation de l’OS ou remplacement du stockage. Cela correspond à une réalité technique, si le malware est implanté dans la mémoire flash contenant le firmware, il n’est pas affecté par ce qui arrive au disque.
Dans un contexte d’entreprise, les conséquences peuvent dépasser le poste isolé. Un poste compromis au niveau boot peut servir de point d’appui pour voler des identifiants, contourner des politiques de sécurité, ou déployer d’autres charges utiles sur le réseau. Dans un contexte grand public, l’impact peut se traduire par un vol de données ou une prise de contrôle silencieuse difficile à diagnostiquer, puisque les outils de sécurité opérant au niveau système voient arriver un environnement déjà altéré.
La difficulté de détection est un facteur aggravant. Les indicateurs classiques, fichiers suspects, services anormaux, peuvent être absents si l’attaque agit avant l’OS et injecte ensuite de manière furtive. La remédiation exige parfois des opérations plus lourdes, mise à jour de firmware, reflash, vérification des paramètres Secure Boot, voire remplacement de la carte mère dans des cas extrêmes. Tout dépend du type d’implant, mais l’idée centrale reste, une fois la barrière Secure Boot contournée, l’attaquant peut s’installer à un endroit où les procédures standard de nettoyage perdent en efficacité.
Cette affaire rappelle aussi une limite de perception, Secure Boot est souvent présenté comme un bouclier universel contre les bootkits, mais sa force dépend de l’actualité de ses listes de confiance et de blocage. Un composant ancien, signé, non révoqué, suffit à rouvrir la possibilité d’une exécution précoce non désirée.
Éléments clés de cette section, bootkit, UEFI, persistance, réinstallation.
Windows et Linux exposés par un même point faible de chaîne de confiance
Le point notable de la source est l’extension du risque au-delà d’un seul système. Les shims ont été conçus pour faciliter le démarrage de Linux sur des machines verrouillées par Secure Boot, mais leur rôle d’intermédiaire les rend utilisables sur des appareils exécutant aussi Windows. Une fois un shim vulnérable en place, il devient une passerelle, l’attaquant ne s’intéresse plus seulement à l’OS, mais à la logique de validation qui précède l’OS. La menace est donc transversale, car c’est le mécanisme de confiance du firmware qui est ciblé.
Dans la pratique, cela signifie qu’un parc mixte, postes Windows, serveurs Linux, stations de travail dual-boot, peut partager une vulnérabilité conceptuelle. Les équipes de sécurité qui compartimentent leurs évaluations par système peuvent passer à côté de ce type de lien, alors que la racine du problème se situe au même endroit, la gestion des signatures et des révocations au niveau Secure Boot.
La responsabilité opérationnelle est aussi diffuse. Microsoft joue un rôle central dans la signature de certains shims, mais la distribution, l’intégration et la mise à jour impliquent d’autres acteurs. Les constructeurs publient des mises à jour UEFI, les distributions Linux publient des shims corrigés, les administrateurs appliquent ou non les mises à jour, et les utilisateurs finaux peuvent laisser des machines hors maintenance. Cette chaîne de dépendances favorise les angles morts, surtout quand des composants anciens restent disponibles en téléchargement ou récupérables depuis des images historiques.
Le sujet met aussi en lumière un dilemme connu, renforcer la sécurité par des blocages stricts peut casser la compatibilité, mais maintenir la compatibilité sans révocation rigoureuse laisse une fenêtre d’exploitation. Les organisations les plus exposées sont souvent celles qui ont des contraintes de continuité, équipements industriels, postes spécialisés, machines anciennes, où l’application d’un blocage peut provoquer un arrêt de production. Dans ces environnements, la gouvernance de Secure Boot doit intégrer des plans de test et de déploiement, pas seulement des recommandations.
Pour les utilisateurs, le message opérationnel est clair, la sécurité du démarrage n’est pas un état acquis une fois pour toutes. Elle dépend de mises à jour, de politiques de clés, et de la capacité des acteurs à retirer de la circulation les composants vulnérables. Dans cette affaire, la source souligne que l’absence de révocation a permis à des shims défectueux de rester un outil de contournement pendant une période très longue, ce qui interroge sur les processus de suivi des binaires signés dans l’écosystème.
Éléments clés de cette section, Windows, Linux, chaîne de confiance, Microsoft.
