Nous avons récemment partagé ici sur le blog l’actualité du problème causé par une mise à jour de Microsoft en dual boot avec les distributions Linux qui utilisent GRUB. Concernant l’incident, nous avons mentionné dans l’article que le “but” de cette mise à jour était de corriger une vulnérabilité GRUB d’il y a deux ans, “CVE-2022-2601” qui permet aux attaquants de contourner les protections de démarrage sécurisées, mais qui est loin d’être une faille. avantage, cela a fini par nuire à de nombreux utilisateurs.
Quelques jours après l’événement, Matthew Garrett, un développeur renommé du noyau Linux, a publié une note dans laquelle il expliquait le fonctionnement du mécanisme SBAT. Dans ce document, il mentionne que SBAT a été conçu pour bloquer les vulnérabilités du chargeur de démarrage sans qu’il soit nécessaire de révoquer les signatures numériques, et a été l’élément central du récent incident provoqué par une mise à jour de Windows qui a affecté certaines distributions Linux sur les systèmes avec démarrage sécurisé UEFI. , l’empêchant de démarrer.
Selon Garrett, Microsoft et certains développeurs Linux partagent la responsabilité du problème : Microsoft pour ne pas avoir testé correctement la mise à jour dans tous les scénarios et les développeurs Linux pour ne pas avoir mis à jour les numéros de génération GRUB et SBAT lorsque des vulnérabilités ont été découvertes dans GRUB.
Garrett mentionne également que lorsque la spécification UEFI Secure Boot a été créée, toutes les personnes impliquées ont sous-estimé dans une certaine mesure sa complexité, car
Le modèle de sécurité de base de Secure Boot stipule que tout le code exécuté dans un environnement privilégié au niveau du noyau doit être vérifié avant son exécution : le micrologiciel vérifie le chargeur de démarrage, le chargeur de démarrage vérifie le noyau et le noyau vérifie tout code supplémentaire chargé au moment de l’exécution. Ainsi, un environnement sécurisé est établi pour appliquer des politiques de sécurité supplémentaires.
De plus, il précise que bien qu’il existe la possibilité de « faire des erreurs » en tant que telles, la spécification inclut un mécanisme pour révoquer les composants signés non fiables : le hachage du code problématique est simplement ajouté à une variable, et le chargement de tout code avec ce hachage, même s’il est signé avec une clé de confiance.
Jusqu’à présent, tout semble bon, mais Garrett mentionne que le problème réside dans l’ampleur et principalement dans la fragmentation de l’écosystème Secure Boot, puisque chaque distribution génère ses propres binaires pour le chargeur de démarrage, chacun avec son propre hachage.
C’est pourquoi il explique que lorsqu’une vulnérabilité est trouvée dans le code source d’un bootloader, un grand nombre de binaires différents doivent être révoqués . De plus, la mémoire disponible pour stocker une variable contenant tous ces hachages est limitée et il n’y a pas assez d’espace pour ajouter un nouvel ensemble de hachages à chaque fois qu’une vulnérabilité est découverte dans GRUB, c’est pourquoi une solution différente était nécessaire.
Cette solution était SBAT.
Le concept de SBAT est relativement simple : chaque composant critique de la chaîne de démarrage déclare un numéro de génération de sécurité qui est inclus dans le binaire signé. Lorsqu’une vulnérabilité est identifiée et corrigée, ce nombre de générations augmente. À partir de là, il est possible d’émettre une mise à jour qui établit la génération minimale acceptable. Les composants de démarrage vérifieront ce numéro pour déterminer s’ils peuvent exécuter l’élément suivant de la chaîne de démarrage, en comparant le nom et le numéro de build aux valeurs stockées dans la variable du micrologiciel.
Au lieu d’avoir à révoquer de nombreux hachages individuels, une seule mise à jour peut dire : “Toute version de GRUB avec une génération de sécurité inférieure à ce nombre est considérée comme non fiable.”
Linux, le vrai responsable
Garrett mentionne que l’erreur qui empêche certains systèmes de démarrer après la mise à jour ne vient pas du code Microsoft, mais du composant shim du chargeur de démarrage Linux.
Bien que Microsoft ait publié la mise à jour SBAT, c’est le chargeur de démarrage Linux qui refuse d’exécuter les anciennes versions de GRUB, ce qui fait que tout fonctionne comme prévu d’un point de vue technique.
C’est pourquoi le vrai problème réside dans le fait que plusieurs distributions Linux n’ont pas publié de versions mises à jour de GRUB intégrant des correctifs de sécurité et de nouvelles générations de SBAT. Cela fait que ces versions de GRUB sont considérées comme dangereuses, puisque shim bloque leur exécution.
Il est important de noter que GRUB est signé par les distributions Linux elles-mêmes, et non par Microsoft, ce qui élimine tout retard externe dans la mise à jour.
Compte tenu de l’explication de Garrett, il mentionne que Microsoft a publié sa mise à jour pour être appliquée uniquement sur Windows (comme il se doit ) et que le problème était dû aux distributions qui géraient toujours les versions vulnérables et généraient le problème du double démarrage.
Enfin, il mentionne que dans cet incident, malheureusement, les principales victimes de cette situation sont les utilisateurs finaux , qui découvrent soudain qu’ils ne peuvent pas démarrer le système d’exploitation qu’ils souhaitent.
C’est quelque chose qui ne devrait jamais arriver. Bien que je comprenne la nécessité d’activer le démarrage sécurisé UEFI par défaut et que je soutiens la décision de Microsoft en général, il est clair que la tentative d’empêcher la mise à jour sur les systèmes à double démarrage n’a pas fonctionné comme prévu.
