Analyse de la nature de SBAT et des problèmes de mise à jour vers Windows, impactant le démarrage de Linux

Matthew Garrett, un développeur du noyau Linux reconnu qui a reçu autrefois un prix du fonds de logiciels libres pour sa contribution au développement de logiciels libres, a expliqué la nature du mécanisme SBAT (Secure Boot Advanced Targeting), conçu pour bloquer les vulnérabilités dans le chargeur de démarrage sans révoquer de signatures numériques, ainsi que son rôle dans l'incident récent lié à une mise à jour de Windows qui a conduit à l'arrêt du démarrage de certaines distributions Linux installées parallèlement à Windows sur des systèmes avec UEFI Secure Boot activé. En résumé, la responsabilité incombe tant à Microsoft, qui n'a pas testé l'ensemble de la mise à jour ni appliqué celle-ci aux systèmes auxquels elle ne devait pas être appliquée, qu'aux développeurs de certaines distributions Linux, qui n'ont pas mis à jour le chargeur GRUB et la version de SBAT lorsque des vulnérabilités ont été découvertes dans GRUB.

Voici la traduction de l'article de Garrett :

Lorsque la spécification UEFI Secure Boot était en cours de développement, tous les participants étaient, disons, un peu naïfs. Le modèle de sécurité principal de Secure Boot stipule que tout code s'exécutant dans un environnement privilégié au niveau du noyau doit être vérifié avant d'être exécuté — le firmware vérifie le chargeur de démarrage, le chargeur de démarrage vérifie le noyau, le noyau vérifie tout code supplémentaire chargé en cours d'exécution, et maintenant nous avons un environnement de confiance pour imposer toute autre politique de sécurité que nous souhaitons. Il est évident que les individus peuvent faire des erreurs, mais la spécification prévoyait un moyen de révoquer les composants signés qui se sont révélés non fiables : il suffisait d'ajouter le hachage du code non fiable à une variable, puis de refuser de charger quoi que ce soit avec ce hachage, même s'il était signé par une clé de confiance.

Malheureusement, il s'avère que le problème est à l'échelle. Chaque distribution Linux fonctionnant dans l'écosystème Secure Boot génère ses propres fichiers binaires de chargeur, et chacun d'eux a son propre hachage. Si une vulnérabilité est trouvée dans le code source d'un tel chargeur, il est nécessaire de révoquer un grand nombre de fichiers binaires différents. Et l'espace mémoire pour stocker la variable contenant tous ces hachages est limité. Il n'y a tout simplement pas assez de place pour ajouter un nouvel ensemble de hachages chaque fois qu'il s'avère que GRUB (le chargeur, à l'origine écrit à une époque où la protection du démarrage n'était pas pratiquée, et ayant plusieurs analyseurs d'images img, ainsi qu'un analyseur de polices) a encore un autre mécanisme pour un attaquant pour le forcer à exécuter du code arbitraire, donc une autre solution était nécessaire.

Cette solution est devenue SBAT. Le concept général de SBAT est assez simple. Chaque composant important de la chaîne de démarrage déclare une génération de sécurité, qui est incluse dans le fichier binaire signé. Lorsque la vulnérabilité est détectée et corrigée, cette génération augmente. Ensuite, une mise à jour peut être émise, définissant la génération minimale — les composants de démarrage vérifieront l'élément suivant de la chaîne, compareront son nom et son numéro de génération avec ceux stockés dans la variable du firmware, et décideront de l'exécuter ou non sur cette base. Au lieu de révoquer un grand nombre de hachages individuels, une seule mise à jour peut être émise, qui dit simplement : « Toute version de GRUB avec une génération de sécurité inférieure à ce numéro est considérée comme non fiable ».

Pourquoi cela est-il devenu soudainement pertinent ? SBAT a été développé conjointement par la communauté Linux et Microsoft, et Microsoft a décidé de publier une mise à jour pour Windows qui a dit aux systèmes de ne pas faire confiance aux versions de GRUB avec une génération de sécurité inférieure à un certain niveau. Cela a été fait car ces versions de GRUB avaient de réelles vulnérabilités de sécurité qui permettaient aux attaquants de compromettre la chaîne de démarrage sécurisée de Windows, et nous avons vu des exemples réels de logiciels malveillants cherchant à le faire (Black Lotus a utilisé une vulnérabilité dans le chargeur Windows, mais la vulnérabilité de GRUB était tout aussi efficace). Vu sous l'angle de la sécurité, c'est un désir tout à fait légitime.

Concernant le message « Quelque chose s'est mal passé » et l'impossibilité de démarrer suite à cette mise à jour, il provient de shim, et non d'un code de Microsoft. Shim prend en compte les mises à jour SBAT, et afin de respecter les principes de sécurité adoptés par d'autres chargeurs dans le système, bien que Microsoft ait publié une mise à jour SBAT, c'est le chargeur Linux qui refuse de lancer les anciennes versions de GRUB. Tout fonctionne comme prévu.

Le problème auquel les gens sont confrontés est que plusieurs distributions Linux n'ont pas publié de versions de GRUB avec une génération de sécurité plus récente, et donc ces versions de GRUB sont considérées comme non sécurisées (il convient de noter que GRUB est signé par les distributions elles-mêmes, et non par Microsoft, il n'y a donc pas de retard introduit de l'extérieur). Selon Microsoft, la mise à jour Windows Update devait appliquer la mise à jour SBAT uniquement aux systèmes fonctionnant exclusivement avec Windows, tandis que toute installation en double démarrage resterait vulnérable aux attaques tant que la distribution installée ne mettrait pas à jour GRUB et ne mettrait pas à jour la génération SBAT. Malheureusement, comme il est désormais évident, cela n'a pas fonctionné comme prévu, et certaines systèmes en double démarrage ont appliqué la mise à jour, alors que Shim de cette distribution a refusé de charger GRUB de cette distribution.

Quel est le résultat ? Microsoft (pour des raisons compréhensibles) ne voulait pas que Windows puisse être attaqué avec une version vulnérable de GRUB, qui pourrait être trompée pour exécuter du code arbitraire et ensuite injecter un bootkit dans le noyau Windows pendant le démarrage. Microsoft a réalisé cela en publiant une mise à jour Windows qui a mis à jour la variable SBAT, indiquant que les versions vulnérables de GRUB ne devaient pas se charger sur ces systèmes. Le chargeur de premier niveau fourni par la distribution lisait cette variable, lisait la section SBAT de la copie GRUB installée, réalisait qu'il y avait un conflit et refusait de charger grub avec le message « Quelque chose s'est mal passé ». Cette mise à jour ne devait pas s'appliquer aux systèmes en double démarrage, mais elle a tout de même été appliquée.

En résumé :

1) Microsoft a appliqué la mise à jour à des systèmes à laquelle elle ne devait pas s'appliquer

2) Certaines distributions Linux n'ont pas mis à jour le chargeur GRUB et la génération de sécurité SBAT lorsque des vulnérabilités ont été découvertes dans GRUB.

En conséquence, certaines personnes ne peuvent pas démarrer leurs systèmes. Je pense qu'il y a beaucoup de responsables ici. Microsoft aurait dû effectuer plus de tests pour s'assurer que les installations en double démarrage peuvent être détectées avec précision. Mais les distributions fournissant des chargeurs signés doivent également s'assurer qu'elles les mettent à jour et actualisent les versions de sécurité pour s'y conformer, sinon elles fournissent un vecteur d'attaque pouvant être utilisé pour compromettre d'autres systèmes d'exploitation, et c'est en quelque sorte une violation du contrat social qui entoure tout cela.

Malheureusement, les victimes ici sont principalement les utilisateurs finaux, confrontés à une situation où le système refuse soudainement de démarrer l'OS qu'ils souhaitent lancer. Cela ne devrait jamais se produire. Je ne pense pas qu'un sondage auprès des utilisateurs finaux sur leur désir d'avoir des mises à jour du système de démarrage sécurisé aura un bon résultat, et bien que je penche en quelque sorte vers le fait que le démarrage sécurisé UEFI n'apporte pas d'avantages à la plupart des utilisateurs finaux, c'est aussi une chose que vous ne voulez pas découvrir après de tels incidents. C'est pourquoi je sympathise avec le fait qu'il soit activé par défaut, donc je soutiens son activation par défaut, partageant le choix de Microsoft, à l'exception de la tentative infructueuse d'éviter les mises à jour sur les systèmes en double démarrage.

Quoi qu'il en soit, j'ai été fortement impliqué dans la mise en œuvre de ce mécanisme pour Linux en 2012 et j'ai écrit le premier prototype de Shim (qui est maintenant un chargeur beaucoup mieux soutenu par un plus large éventail de personnes, et auquel je n'ai pas touché depuis plusieurs années). Donc, si vous voulez accuser quelqu'un, n'hésitez pas à m'accuser. C'est quelque chose qui ne devrait pas arriver, et si vous n'êtes pas Microsoft ou une distribution Linux, ce n'est pas de votre faute. Je m'excuse.

Source : opennet.ru