Vulnérabilité de UEFI SecureBoot dans GRUB2 — 2021

Depuis la série de bogues « BootHole » de GRUB2 annoncés en juillet 2020, les chercheurs en sécurité et les développeurs de Debian et d'ailleurs ont poursuivi leur recherche de nouveaux problèmes qui pourraient permettre de contourner l'amorçage sécurisé (Secure Boot — SB) avec UEFI. Plusieurs autres ont été découverts. Consultez l'annonce de sécurité dsa-4867-1 pour plus de détails. Le but de ce document est d'expliquer les conséquences de cette vulnérabilité de sécurité et les étapes pour sa suppression.

Contexte : qu'est-ce que l'amorçage sécurisé avec UEFI ?

UEFI Secure Boot (SB) est un mécanisme de vérification pour s'assurer que le code chargé par le microcode UEFI d'un ordinateur est de confiance. Il est conçu pour protéger une machine contre du code malveillant qui serait chargé et exécuté dans le processus d'amorçage initial, avant que le système d'exploitation ne soit chargé.

SB fonctionne à l'aide de sommes de contrôle et de signatures de chiffrement. Chaque programme chargé par le microcode comprend une signature et une somme de contrôle, et avant d'en permettre l'exécution, le microcode vérifie que le programme est de confiance en validant la somme de contrôle et la signature. Quand SB est actif sur une machine, toute tentative pour exécuter un programme qui n'est pas de confiance est interdite. Cela empêche que du code non prévu ou non autorisé ne soit exécuté dans l'environnement d'UEFI.

La plupart des matériels X86 sont livrés d'usine préchargés avec les clés de Microsoft. Cela signifie que le microcode présent sur ces machines fera confiance aux binaires signés par Microsoft. Les machines les plus modernes sont livrées avec SB activé — par défaut, elles n'exécutent aucun code non signé, mais il est possible de modifier la configuration du microcode soit pour désactiver SB, soit pour inscrire des clés supplémentaires.

Debian, comme beaucoup d'autres systèmes d'exploitation basés sur Linux, utilise un programme nommé shim pour étendre ce système de confiance du microcode à d'autres programmes qui nécessitent d'être sécurisés durant l'amorçage initial : le chargeur d'amorçage GRUB2, le noyau Linux et les outils de mise à jour du microcode (fwupd et fwupdate).

Plusieurs bogues découverts dans GRUB2

Un bogue a été découvert dans le module acpi de GRUB2. Ce module est conçu pour fournir une interface de pilote pour ACPI (« Advanced Configuration and Power Interface »), un composant très commun du matériel des ordinateurs actuels. Malheureusement, le module ACPI permet aussi actuellement à un utilisateur privilégié de charger des tables ACPI contrefaites avec l'amorçage sécurisé et d'effectuer des modifications arbitraires dans l'état du système ; cela permet de briser facilement la chaîne d'amorçage sécurisé. Cette faille de sécurité a maintenant été corrigée.

Comme cela a été fait avec BootHole, plutôt que de corriger uniquement ce bogue, les développeurs sont allés plus loin avec un audit et une analyse en profondeur du code source de GRUB2. Il aurait été irresponsable de ne corriger qu'un défaut majeur sans également en rechercher d'autres ! Nous avons découvert quelques autres emplacements où des allocations de mémoire interne pourraient subir des dépassements avec des entrées non prévues et quelques emplacements où la mémoire pourrait être utilisée après sa libération. Des correctifs pour tout cela ont été partagés et testés dans toute la communauté.

De nouveau, veuillez consulter l'annonce de sécurité dsa-4867 de Debian pour une liste complète des problèmes découverts.

Des révocations de clés nécessaires pour corriger la chaîne d'amorçage sécurisé

Debian et d'autres fournisseurs de systèmes d'exploitation vont évidemment publier des versions corrigées de GRUB2. Néanmoins, cela ne peut pas corriger complètement le problème traité ici. Des acteurs malveillants pourraient encore utiliser des versions vulnérables plus anciennes de GRUB2 pour contourner l'amorçage sécurisé.

Pour mettre un terme à cela, l'étape suivante pour Microsoft sera de bloquer ces binaires non sûrs pour les empêcher d'être exécutés par SB. Cette démarche est réussie en chargeant la liste DBX, une fonctionnalité de la conception d'UEFI Secure Boot. Il a été demandé à toutes les distributions Linux livrées avec des copies de shim signées par Microsoft de fournir des détails sur les binaires ou les clés concernés pour faciliter ce processus. Le fichier de la liste de révocations d'UEFI sera mis à jour pour inclure cette information. À un certain moment dans le futur, les machines commenceront à utiliser cette liste mise à jour et refuseront d'exécuter les binaires vulnérables avec Secure Boot.

La chronologie exacte du déploiement de ce changement n'est pas encore fixée. Les fournisseurs de BIOS et UEFI vont inclure la nouvelle liste de révocations dans les constructions de microcode pour le matériel neuf à un certain moment. Microsoft peut aussi publier des mises à jour pour des systèmes existants au moyen de Windows Update. Il est possible que certaines distributions Linux fassent des mises à jour à l'aide de leur propre processus de mises à jour de sécurité. Debian n'a pas encore fait cela, mais nous nous penchons sur la question pour le futur.

Quels sont les effets de la révocation de clés ?

La plupart des fournisseurs hésitent à appliquer automatiquement des mises à jour qui révoquent les clés utilisées pour Secure Boot. Les installations logicielles existantes avec SB activé peuvent brusquement refuser totalement de démarrer, à moins que l'utilisateur prenne soin d'installer également toutes les mises à jour logicielles nécessaires. Les machines bénéficiant du dual boot Windows/Linux peuvent soudain cesser de démarrer avec Linux. Les anciens médias d'installation et les médias autonomes échoueront bien sûr aussi à démarrer, rendant potentiellement encore plus difficile la récupération des systèmes.

Il y a deux manières évidentes de corriger une machine qui refuse de démarrer :

Ces deux options semblent simples, mais chacune peut prendre beaucoup de temps aux utilisateurs qui ont de multiples machines. Aussi soyez conscient qu'activer ou désactiver Secure Boot nécessite, de par sa conception, un accès direct à la machine. Il n'est normalement pas possible de modifier cette configuration en dehors du réglage du microcode de l'ordinateur. Pour cette raison précise, les machines qui sont des serveurs distants doivent faire l'objet d'un soin particulier.

Pour ces raisons, il est fortement recommandé à tous les utilisateurs de Debian de prendre la précaution d'installer toutes les mises à jour recommandées pour leurs machines dès que possible, afin de réduire le risque de problèmes à l'avenir.

Paquets et clés mis à jour

Note : Les machines qui fonctionnent avec Debian 9 (Stretch) et les versions antérieures ne recevront pas forcément de mise à jour dans la mesure où Debian 10 (Buster) est la première des versions de Debian à inclure la prise en charge de UEFI Secure Boot.

Cinq paquets source de Debian seront mis à jour du fait des modifications de UEFI Secure Boot décrites ici :

1. GRUB2

Les versions mises à jour des paquets de GRUB2 pour Debian sont maintenant disponibles au moyen de l'archive debian-security pour la version stable Debian 10 (Buster). Les versions corrigées seront très bientôt dans l'archive normale de Debian pour les versions de développement de Debian (unstable et testing).

2. Linux

Les versions mises à jour des paquets linux pour Debian seront prochainement disponibles au moyen de buster-proposed-updates pour la version stable Debian 10 (Buster) et seront inclus dans la version intermédiaire 10.10 à venir. De nouveaux paquets seront bientôt dans l'archive Debian pour les versions de développement de Debian (unstable et testing). Nous espérons avoir également bientôt des paquets mis à jour versés dans buster-backports.

3. Shim et SBAT

La série de bogues de « BootHole » marquait la première fois qu'une révocation de clés à grande échelle était nécessaire dans l'écosystème d'UEFI Secure Boot. Elle a démontré une malheureuse faiblesse de conception dans la révocation de SB : à cause du grand nombre de distributions Linux distinctes et de binaires d'UEFI, la taille de la liste de révocation croit rapidement. De nombreux systèmes informatiques n'ont qu'un espace limité pour stocker les données de révocation de clés, pouvant se remplir très rapidement et laisser ces systèmes cassés de diverses manières.

Pour lutter contre ce problème, les développeurs de shim ont conçu une méthode beaucoup plus efficace en matière d'espace pour bloquer les binaires non sûrs d'UEFI à l'avenir. Elle est nommée SBAT (Secure Boot Advanced Targeting). Elle fonctionne en suivant les numéros de création des programmes signés. Plutôt que de révoquer les signatures individuellement quand des problèmes sont détectés, des compteurs sont utilisés pour indiquer que les versions anciennes des programmes ne sont plus considérées comme sûres. Révoquer une série ancienne de binaires de GRUB2 (par exemple) devient maintenant un cas de mise à jour d'une variable d'UEFI contenant le numéro de création de GRUB2 ; toute version du logiciel GRUB2 antérieure à ce numéro ne sera plus considérée comme sûre. Pour plus d'informations sur SBAT, consultez la documentation de SBAT de shim.

Malheureusement, ce nouveau travail de développement de SBAT dans shim n'est pas encore tout à fait prêt. Les développeurs visaient à publier maintenant une version de shim avec cette nouvelle fonctionnalité majeure, mais ils ont rencontré des difficultés inattendues. Le développement est toujours en cours. Dans toute la communauté Linux, nous prévoyons de mettre à jour cette nouvelle version de shim très bientôt. Jusqu'à ce qu'elle soit prête, nous allons tous continuer à utiliser nos binaires actuels de shim.

Les versions mises à jour des paquets shim de Debian seront disponibles dès que ce travail sera achevé. Ils seront annoncés ici et ailleurs. Nous publierons la nouvelle version intermédiaire 10.10 à ce moment-là ainsi que de nouveaux paquets shim pour les versions de développement de Debian (unstable et testing).

4. Fwupdate

Les versions mises à jour des paquets fwupdate de Debian seront bientôt disponibles au moyen de buster-proposed-updates pour la version stable Debian 10 (Buster) et seront inclus dans la version intermédiaire 10.10 à venir. fwupdate a déjà été retiré d'unstable et de testing il y a un moment en faveur de fwupd.

5. Fwupd

Les versions mises à jour des paquets fwupd de Debian seront bientôt disponibles au moyen de buster-proposed-updates pour la version stable Debian 10 (Buster) et seront inclus dans la version intermédiaire 10.10 à venir. De nouveaux paquets sont aussi dans l'archive Debian pour les versions de développement de Debian (unstable et testing).

6. Clés

Debian a généré des clés de signature et des certificats pour ses paquets Secure Boot. Jusqu'à présent, nous utilisions un seul certificat pour tous nos paquets :

Nous avons évolué vers l'utilisation de clés et de certificats distincts pour chacun des cinq paquets source impliqués, pour obtenir plus de souplesse à l'avenir :

Version intermédiaire Debian 10.10 (Buster), médias d'installation et autonomes mis à jour

Il est prévu que tous les correctifs décrits ici soient inclus dans la version intermédiaire Debian 10.10 (Buster), qui doit être publiée bientôt. Cette version 10.10 devrait donc être un bon choix pour les utilisateurs qui recherchent des médias d'installation et autonomes. Les images plus anciennes peuvent cesser de fonctionner avec Secure Boot à l'avenir, lorsque les révocations seront déployées.

Plus d'informations

Beaucoup plus d'informations sur la configuration de l'amorçage sécurisé de Debian se trouvent dans le wiki de Debian — voir https://wiki.debian.org/SecureBoot.

Parmi les autres ressources sur ce sujet :