Secure Boot est un mécanisme clé pour la sécurité des PC, mais une faille insidieuse a persisté pendant plus d’une décennie. Microsoft vient enfin d’y mettre fin en révoquant des chargeurs vulnérables qui laissaient passer des attaques. Retour sur une négligence qui aurait pu coûter cher.
Cette faille touche à l’un des premiers remparts lors du démarrage d’un appareil. Elle concernait des « shims », des petits chargeurs intermédiaires, signés par Microsoft et encore reconnus fiables malgré leurs vulnérabilités. Comment cela a-t-il pu durer aussi longtemps ?
La réponse réside dans le fonctionnement même de Secure Boot et sa gestion des certificats. Microsoft a actionné la liste de révocation en juin dernier, mais le problème soulève des questions sérieuses sur la maintenance de cette sécurité critique.
Microsoft neutralise des chargeurs UEFI vulnérables validés par Secure Boot depuis 2011
Il faut comprendre que Secure Boot contrôle les composants lancés avant le système. Ce contrôle est basé sur une chaîne de confiance fournie par des signatures numériques. Le firmware UEFI vérifie cette signature avant d’autoriser l’exécution d’un binaire.
Or, onze shims datant de 2015 ou plus anciens, tous signés par Microsoft, figuraient parmi les éléments approuvés. Ces chargeurs pouvaient être exploités pour injecter un malware dès le démarrage, avant même que Windows ne tourne. Une porte ouverte que les attaquants pouvaient utiliser pour déployer des bootkits difficiles à détecter.
Les chercheurs en cybersécurité d’ESET ont révélé cette vulnérabilité en février 2026. Microsoft a réagi en ajoutant ces chargeurs à sa base de révocation – la DBX. La mise à jour KB5094126 en juin puis KB5101650 en juillet ont permis de désactiver définitivement ces scripts mal sûrs.
Secure Boot ne bloque pas automatiquement les fichiers signés expirés
Un détail important explique comment cette faille a pu persister. Secure Boot ne considère pas la date d’expiration du certificat utilisé pour signer un binaire. Tant qu’un élément n’est pas explicitement blacklisté dans la DBX, il reste considéré comme fiable.
C’est la raison pour laquelle, malgré l’expiration du certificat Microsoft utilisé pour ces shims au 27 juin 2026, les chargeurs vulnérables étaient encore acceptés jusqu’à l’inclusion dans la DBX. Cette nuance technique n’est pas anodine. Elle révèle une faiblesse dans la gestion opérationnelle de la sécurité UEFI.
Le patch cumulatif de juillet a donc fait plus que corriger un bug classique. Il a mis à jour la base de révocation pour couper court à ces failles longtemps ignorées.
Une faille qui concerne aussi Linux via les shims UEFI
On associe souvent Secure Boot uniquement à Windows, mais il protège aussi d’autres OS. Les shims sont notamment utilisés par Linux pour assurer la chaîne de confiance. Ils permettent d’éviter que l’UEFI bloque un noyau Linux non signé directement.
Ces petits chargeurs intermédiaires sont essentiels, mais doivent être sans faille. Or, les même shims vulnérables qui ont affecté Windows pouvaient également servir à lancer des attaques sous Linux. C’est une faille transversale, bien plus préoccupante qu’un simple bug isolé.
Sans mise à jour du shim ou révocation rapide, une attaque bootkit aurait pu passer facilement. Le risque ? Exécuter un code malveillant avant le démarrage du système, empêchant toute détection classique.
La DBX, un garde-fou essentiel mais pas infaillible
La DBX est une base de données qui répertorie tous les certificats et binaires UEFI refusés par Secure Boot. Ajouter un élément à cette liste revient à lui retirer la confiance. C’est le seul moyen efficace de bloquer les composants malicieux déjà signés.
Malheureusement, cette mesure est aussi une dépendance forte. Si la DBX n’est pas régulièrement mise à jour, des éléments dangereux restent utilisables. Pire, la plupart des shims signés avant 2017 ne sont pas encore catalogués publiquement. Qui sait combien d’entre eux restent vulnérables ?
Cette faille montre que « faire confiance » sans vérifier n’est jamais une stratégie viable. La vigilance et la réponse rapide doivent être la norme pour garantir une sécurité réelle.
La démonstration de la faille Secure Boot, réalisée par des chercheurs, a montré à quel point la sécurité basse couche est fragile. On touche ici à un aspect fondamental souvent sous-estimé !
La clé pour éviter de futures négligences Secure Boot
Ce cas met en lumière un enjeu critique : la maintenance continue du système de sécurité. Une architecture fiable ne s’en tient pas à une promesse initiale, elle vérifie ses fondations sans cesse. Ignorez cette règle, et la résilience s’écroule.
Les mises à jour ne doivent pas être un simple patch mais un véritable audit permanent. Cela implique de cataloguer tous les éléments signés et de révoquer sans délai ceux qui représentent un risque.
Sans cela, on garde une illusion de sécurité. Et dans le monde connecté d’aujourd’hui, cela peut coûter bien plus que des heures de dépannage.
Source: www.clubic.com
Commentaires
Laisser un commentaire