Qu’est-ce que SBAT et pourquoi tout le monde s’y intéresse soudainement ?

Définition de SBAT (Secure Boot Advanced Targeting)

• Lorsque l’UEFI Secure Boot a été défini pour la première fois, toutes les parties concernées étaient quelque peu naïves
• Le modèle de sécurité de base de Secure Boot repose sur le fait que tout code exécuté dans un environnement à privilèges de niveau noyau doit être vérifié avant exécution
• Il inclut une méthode permettant de révoquer des composants signés lorsqu’une vulnérabilité est découverte
• Cependant, comme toutes les distributions Linux fonctionnant dans l’écosystème Secure Boot génèrent leur propre binaire de chargeur d’amorçage, lorsqu’une vulnérabilité est identifiée, il y a de nombreux binaires à révoquer
• L’espace disponible pour stocker les hachages étant limité, SBAT a été développé

Fonctionnement de SBAT

• Tous les composants importants de la chaîne de démarrage déclarent une génération de sécurité incluse dans le binaire signé
• Lorsqu’une vulnérabilité est identifiée puis corrigée, cette génération est incrémentée
• Une mise à jour peut définir une génération minimale
• Un composant de démarrage examine l’élément suivant dans la chaîne, compare son nom et son numéro de génération à ce qui est stocké dans une variable du firmware, puis décide s’il doit l’exécuter
• Au lieu de révoquer un grand nombre de hachages individuels, on peut déployer une seule mise à jour indiquant que les versions de grub ayant une génération de sécurité inférieure à un certain numéro ne sont plus dignes de confiance

Cause du problème récent

• Microsoft a publié une mise à jour Windows pour ne plus faire confiance aux versions de grub dont la génération de sécurité est inférieure à un certain niveau
• Cela s’explique par le fait que ces versions de grub comportent de véritables vulnérabilités de sécurité pouvant compromettre la chaîne de démarrage sécurisé de Windows
• Le problème est que certaines distributions Linux n’avaient pas encore fourni de nouvelle version de grub avec une génération de sécurité mise à jour
• L’intention de Microsoft était d’appliquer la mise à jour SBAT uniquement aux systèmes Windows seuls, mais cela n’a pas fonctionné comme prévu

Résumé

• Microsoft a poussé une mise à jour Windows pour empêcher qu’une version vulnérable de grub puisse être utilisée pour attaquer Windows
• Cette mise à jour était censée ne pas s’appliquer aux systèmes en dual boot, mais cela a été ignoré
• Certaines distributions Linux n’avaient pas mis à jour le code de grub ni la génération de sécurité SBAT
• En conséquence, certains utilisateurs ne pouvaient plus démarrer leur système

Qui blâmer

• Microsoft aurait dû effectuer davantage de tests afin d’identifier correctement les configurations en dual boot
• Mais les distributions qui fournissent un chargeur d’amorçage signé doivent également le mettre à jour et faire évoluer la génération de sécurité
• En effet, cela peut fournir un vecteur permettant d’attaquer d’autres systèmes d’exploitation

Conclusion

• Il est regrettable que les utilisateurs finaux, qui se sont soudainement retrouvés incapables de démarrer l’OS de leur choix, en aient été les victimes
• Cela n’aurait jamais dû arriver
• Même si l’on peut avoir l’impression que l’UEFI Secure Boot n’apporte aucun bénéfice à la plupart des utilisateurs finaux, on n’a pas envie de découvrir après coup qu’on en avait besoin ; je comprends donc le choix de Microsoft de l’activer par défaut
• À l’exception de cette tentative ratée d’éviter la mise à jour sur les systèmes en dual boot, je comprends les choix de Microsoft

Avis de GN⁺

• Cet incident montre à quel point il est difficile de trouver un équilibre entre sécurité et expérience utilisateur
• Microsoft et les distributions Linux font toutes deux de leur mieux pour protéger les utilisateurs, mais l’expérience utilisateur peut en pâtir au cours du processus
• Les utilisateurs de systèmes en dual boot sont davantage susceptibles d’être confrontés à ce type de problème
• Il est donc important, pour les utilisateurs du dual boot, de maintenir les deux systèmes d’exploitation à jour et d’effectuer des mises à jour régulières
• À long terme, une meilleure coopération et une meilleure coordination entre les communautés Linux et Windows semblent nécessaires

[GN⁺]

Avis Hacker News

• Un épisode récent de Linux Unplugged expliquait comment utiliser un TPM pour établir une chaîne de confiance dans le processus de démarrage de Linux, avec Clevis ; c’était très intéressant
• L’intention de Microsoft semblait être que Windows Update n’applique les mises à jour SBAT qu’aux systèmes exclusivement Windows, et que les configurations en dual boot restent vulnérables jusqu’à ce que la distribution installée mette à jour grub et diffuse elle-même la mise à jour SBAT
  • En lisant l’ordre de démarrage EFI, il devrait pourtant être clairement indiqué qu’il faut démarrer shim en premier ; je me demande ce qui s’est mal passé
  • Je me demande si cela concernait les configurations en dual boot où l’utilisateur choisit Linux ou Windows via le menu du firmware
  • Cela ressemble à un correctif légitime de la part de Microsoft, mais la communication a été mauvaise
• Je déteste vraiment les messages d’erreur en cas d’échec d’une vérification de sécurité de shim ou de Secure Boot en général ; j’aimerais qu’ils indiquent précisément ce qui a échoué et comment le corriger
• Je pense que l’une des raisons pour lesquelles MS impose le TPM 2.0 et applique les mises à jour SBAT est l’existence de malwares très répandus au niveau rootkit
• Concernant la réalité du dual boot, il y a 10 ans, avec Win7/8/10, il y avait beaucoup de problèmes liés à suspend-to-hiberfile.sys et à des mises à jour qui cassaient grub
  • J’ai décidé il y a 10 ans de n’utiliser que Linux, et d’utiliser une VM si nécessaire, ou bien un autre ordinateur de secours distinct
  • Depuis, j’ai appris à configurer correctement Secure Boot sur des distributions, à ajuster les performances et le passthrough de QEMU, et j’ai même réussi à faire fonctionner une VM macOS sous QEMU
  • C’est pénible de devoir faire des mises à jour tous les quelques mois pour conserver XCode, mais globalement j’en suis satisfait
• La première chose à faire lors de l’installation de Linux n’est-elle pas de désactiver Secure Boot ?
• La question principale est de savoir si le grub refusé n’était pas entièrement patché, ou si la distribution l’avait patché sans mettre à jour la « génération de sécurité »
  • Je suis très curieux de savoir comment MS a tenté de détecter le dual boot, et j’aimerais que quelqu’un de plus compétent rétroconçoive cette partie de la mise à jour
• La raison pour laquelle Microsoft a cassé les systèmes en dual boot est d’éviter de fournir un vecteur permettant d’attaquer un autre système d’exploitation, et c’est une violation du contrat social
• Je me demande si cela gêne la suppression de Windows du système pour installer Linux, ou si l’installation de Windows pollue durablement le module TPM
• Je me demande s’il est possible de mettre à jour grub depuis Windows, ou s’il suffit de désactiver Secure Boot, de démarrer Linux, de faire la mise à niveau, puis de le réactiver
• La position de MS consistant à bloquer les anciennes installations vulnérables de grub semble raisonnable, mais je n’utilise Windows que pour les jeux et un unique logiciel legacy, sans accès réseau
  • À partir du moment où l’on autorise Windows Update, tout repose sur la chance
  • Le fait que MS déplace les clés de registre et joue des tours aux utilisateurs pour imposer la « télémétrie » (ML pour le scan publicitaire et des données comportementales) en dit long
  • Cela arrive aussi sur Windows Pro, et j’utilise Win 10