Onze shims signés par Microsoft contournent Secure Boot
Onze chargeurs de démarrage UEFI, signés par Microsoft et disponibles depuis plusieurs années, ont permis de contourner la protection Secure Boot sur presque toutes les machines UEFI, qu’elles fonctionnent sous Windows ou Linux. L’exploitation de cette faille nécessitait simplement de copier un ancien binaire sur la partition EFI.
Onze shims oubliés, une signature jamais retirée
Lorsque le Secure Boot est activé sur un PC, le firmware UEFI vérifie chaque application de démarrage à l’aide de deux bases de données : db, qui répertorie les éléments autorisés, et dbx, qui liste ceux interdits. La plupart des fabricants intègrent dès l’usine le certificat Microsoft Corporation UEFI CA 2011 dans db, qui signe les composants de démarrage tiers. Ce fonctionnement requiert que chaque nouvelle version de GRUB 2 ou du noyau soit validée par Microsoft, ce qui n’est pas viable, d’où l’utilisation des shims.
Ces chargeurs, signés une seule fois par Microsoft, intègrent le certificat de l’éditeur et vérifient les composants suivants, comme GRUB 2, qui charge ensuite le noyau. Cela permet à une distribution Linux de publier ses mises à jour sans avoir à repasser par Microsoft. La confiance du firmware s’arrête au shim, le reste en découle.
Le problème identifié par Martin Smolár, chercheur chez ESET, est que ces vieux shims n’ont jamais été révoqués. Au total, 11 binaires en version 0.9 ou antérieure sont concernés et exploitables sur n’importe quelle machine qui fait confiance au certificat de 2011, quel que soit le système d’exploitation. Les solutions concernées incluent :
- Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2 et ROSA Linux R9/R10 (shim 0.9)
- Deux binaires côté OpenSUSE, dont le shim 2.1 (shim 0.9)
- PC-Doctor Service Center 15 et 16 (shim 0.9)
- baramundi Management Suite, jusqu’à la version 2024R1 (shim 0.8)
- Abitti 1.0, signé pour le Matriculation Examination Board finlandais (shim 0.8)
- WipeDrive de WhiteCanyon/Blancco 8.0.0 à 8.1.3, et Spyrus WTGCreator (shim 0.7 ou antérieur)
ESET a alerté le CERT/CC le 16 février 2026. La révocation a été publiée le 9 juin 2026, suite à la distribution des shims de remplacement par les éditeurs. Deux failles sont associées à ce problème : CVE-2026-8863 et CVE-2026-10797.
Aucun exploit inédit, un simple copier-coller suffit
Le logiciel vulnérable n’a pas besoin d’être installé sur la cible : l’attaquant peut apporter sa propre copie du shim et du binaire, les déposer sur la partition système EFI, et la chaîne de confiance les acceptera. Bien qu’un simple copier-coller suffise, il est nécessaire de disposer des privilèges requis sur la machine.
Selon le rapport d’ESET, un seul shim peut valider plusieurs binaires, et les horodatages de signature et de compilation de ces binaires vont de 2013 à 2025. Le rapport précise que le nombre de fichiers binaires considérés comme fiables par un shim donné varie de moins de dix pour des logiciels spécialisés à près d’une centaine pour des distributions Linux bien connues.
ESET fournit trois exemples de la surface d’attaque exposée :
- Le shim d’Oracle Linux 7.2 fait confiance à un GRUB 2 présent dans l’ISO d’Oracle Linux 7.1, affecté par la CVE-2015-5281.
- Le shim 0.8 d’Abitti ignore la liste de révocation
MokListX. - Le shim 0.9 de Red Hat Enterprise Linux 7.2 ne consulte jamais la politique
SbatLevel.
Un autre problème, la CVE-2026-10797, corrigée il y a près de dix ans mais restée sans identifiant jusqu’à ce signalement, permettait de faire porter le contrôle de révocation sur des données factices.
Conclusion
L’expiration du certificat Microsoft Corporation UEFI CA 2011, survenue le 27 juin 2026, n’a pas d’impact sur la vérification. Les binaires signés restent dignes de confiance tant que le certificat est présent dans db et non révoqué dans dbx. Pour se protéger, il est recommandé d’appliquer les dernières révocations UEFI de Microsoft, distribuées depuis juin 2026.
Pour Windows, la mise à jour de dbx se fait via Windows Update. Sur Linux, elle passe par le Linux Vendor Firmware Service et peut être vérifiée avec le script uefi-dbx-audit.
Source : ESET / WeLiveSecurity
