Les développeurs de Fedora Linux ont clarifié la situation concernant l'expiration, à la fin juin, du certificat Microsoft utilisé pour signer numériquement le shim, qui est utilisé pour le démarrage vérifié des distributions Linux en mode UEFI Secure Boot. La transition vers un nouveau certificat devra se faire sans que les utilisateurs s'en aperçoivent, car en réalité, la fin de la durée de vie du certificat entraînera seulement l'impossibilité de l'utiliser pour créer de nouvelles signatures. Au démarrage en mode UEFI Secure Boot, la durée de vie du certificat n'est pas vérifiée et seul le retrait des certificats compromis est important.
Les systèmes existants sans mise à jour de shim continueront à démarrer tant que la clé publique du certificat ne sera pas supprimée du firmware ou ajoutée à la liste des certificats révoqués UEFI (DBX). La clé de Microsoft ne signe que le shim de démarrage, qui contient la clé publique de la distribution, utilisée pour signer les composants chargés, tels que le chargeur GRUB2, le noyau Linux, les modules de noyau et les processus utilisés au démarrage, tels que fwupd. Cette approche permet à Microsoft de signer uniquement les modifications du shim et d'assurer indépendamment la vérification du processus de démarrage de la distribution.
Le certificat Microsoft pour la signature des firmwares tiers pour UEFI Secure Boot est en vigueur depuis 2011. En 2023, un nouveau certificat a été généré pour être utilisé pour la création de signatures à partir d'octobre 2025. Le dépôt Fedora Rawhide, sur lequel est basé le release de Fedora 45, a déjà intégré un shim mis à jour, signé par plusieurs clés pour assurer la compatibilité maximale avec le matériel (pouvant être utilisé à la fois sur d'anciens firmwares sans clé publique du nouveau certificat et sur des firmwares sans clé publique de l'ancien certificat).
Bien que l'expiration du certificat Microsoft ne devrait pas affecter le fonctionnement du démarrage, les développeurs de Fedora recommandent aux utilisateurs de mettre à jour la base de données avec les clés pour Secure Boot lors de la publication de nouvelles versions de micrologiciels pour leur matériel. Pour déterminer si le système a démarré en mode UEFI Secure Boot, vous pouvez utiliser la commande « mokutil —sb-state », et pour afficher la liste des clés ouvertes présentes dans le micrologiciel, utilisez « mokutil —db —short ». Pour voir les clés avec lesquelles la couche shim est signée, vous pouvez exécuter la commande « sudo pesign -S -i /boot/efi/EFI/fedora/shimx64.efi », après avoir installé le paquet pesign. Pour vérifier la disponibilité d'une mise à jour du micrologiciel et son installation, vous pouvez exécuter la commande « sudo fwupdmgr update ».
La prochaine version de la couche shim sera signée uniquement avec un nouveau certificat Microsoft et la mise à jour du micrologiciel est nécessaire pour préparer vos systèmes à ce changement. La mise à jour de shim sera publiée en cas de vulnérabilités ou de bogues graves, ce qui peut se produire tant dans un mois que dans un an. Depuis l'introduction de shim dans le projet, des vulnérabilités critiques ont été découvertes, le dernier rapport sur les problèmes de sécurité concernant shim ayant été publié il y a seulement quelques jours.
Le rapport note deux vulnérabilités récemment découvertes, CVE-2026-8863 et
CVE-2026-10797, permettant d'exécuter son propre code au début du démarrage avant de passer le contrôle au système d'exploitation, de contourner la protection UEFI Secure Boot et de permettre le chargement de composants du noyau non signés numériquement. Les problèmes concernent les versions de shim jusqu'à la version 0.9 incluant, formées avant 2016. Les systèmes très anciens, tels que
RedHat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, ROSA Linux R10/R9 et openSUSE avec shim 0.9, sont vulnérables. Les couches shim jusqu'à la version 0.9 inclusivement ont été ajoutées à la base des signatures numériques révoquées DBX (UEFI Forbidden Signature Database) et, en cas de mise à jour de DBX, ne pourront plus être utilisées pour démarrer en mode UEFI Secure Boot dans le système.
Source : opennet.ru
