Getty Images
Mardi dernier, de nombreux utilisateurs de Linux, dont beaucoup utilisent des packages sortis dès cette année, ont commencé à signaler que leurs appareils ne démarraient pas. Au lieu de cela, ils ont reçu un message d’erreur cryptique contenant la phrase suivante : « Quelque chose s’est sérieusement mal passé. »
La cause : une mise à jour publiée par Microsoft dans le cadre de sa publication mensuelle de correctifs. Elle était destinée à combler une vulnérabilité vieille de 2 ans dans GRUB, un chargeur de démarrage open source utilisé pour démarrer de nombreux appareils Linux. Cette vulnérabilité, dont la gravité est de 8,6 sur 10, permettait aux pirates de contourner le démarrage sécurisé, la norme industrielle permettant de garantir que les appareils exécutant Windows ou d’autres systèmes d’exploitation ne chargent pas de micrologiciels ou de logiciels malveillants pendant le processus de démarrage. La vulnérabilité CVE-2022-2601 a été découverte en 2022, mais pour des raisons obscures, Microsoft ne l’a corrigée que mardi dernier.
Plusieurs distributions, nouvelles et anciennes, sont affectées
La mise à jour de mardi a empêché les périphériques à double démarrage (c’est-à-dire ceux configurés pour exécuter à la fois Windows et Linux) de démarrer sous ce dernier lorsque le démarrage sécurisé a été appliqué. Lorsque les utilisateurs ont essayé de charger Linux, ils ont reçu le message suivant : « La vérification des données SBAT du shim a échoué : violation de la politique de sécurité. Quelque chose s’est sérieusement mal passé : échec de l’auto-vérification SBAT : violation de la politique de sécurité. » Presque immédiatement, les forums de support et de discussion se sont illuminés avec des rapports sur l’échec.
« Notez que Windows indique que cette mise à jour ne s’appliquera pas aux systèmes qui démarrent en double Windows et Linux », a écrit une personne frustrée. « Ce n’est évidemment pas vrai, et cela dépend probablement de la configuration de votre système et de la distribution exécutée. Il semble que cela ait rendu certains chargeurs de démarrage efi shim Linux incompatibles avec les chargeurs de démarrage efi de Microcrap (c’est pourquoi le passage de MS efi à « un autre système d’exploitation » dans la configuration efi fonctionne). Il semble que Mint dispose d’une version shim que MS SBAT ne reconnaît pas. »
Les rapports indiquent que plusieurs distributions, dont Debian, Ubuntu, Linux Mint, Zorin OS et Puppy Linux, sont toutes concernées. Microsoft n’a pas encore reconnu publiquement l’erreur, expliqué pourquoi elle n’a pas été détectée lors des tests, ni fourni de conseils techniques aux personnes concernées. Les représentants de l’entreprise n’ont pas répondu à un e-mail demandant des réponses.
[Update: Roughly 17 hours after this post went live, Microsoft supplied the following statement, which also doesn’t answer those questions: “This update is not applied when a Linux boot option is detected. We are aware that some secondary boot scenarios are causing issues for some customers, including when using outdated Linux loaders with vulnerable code. We are working with our Linux partners to investigate and address.”]
Le bulletin de Microsoft pour CVE-20220-2601 expliquait que la mise à jour installerait un SBAT (un mécanisme Linux permettant de révoquer divers composants dans le chemin de démarrage), mais uniquement sur les appareils configurés pour exécuter uniquement Windows. De cette façon, Secure Boot sur les appareils Windows ne serait plus vulnérable aux attaques qui chargeraient un package GRUB exploitant la vulnérabilité. Microsoft a assuré aux utilisateurs que leurs systèmes à double démarrage ne seraient pas affectés, bien qu’il ait averti que les appareils exécutant des versions plus anciennes de Linux pourraient rencontrer des problèmes.
« La valeur SBAT ne s’applique pas aux systèmes à double démarrage qui démarrent à la fois Windows et Linux et ne devrait pas affecter ces systèmes », peut-on lire dans le bulletin. « Il se peut que les ISO de distribution Linux plus anciennes ne démarrent pas. Si cela se produit, contactez votre fournisseur Linux pour obtenir une mise à jour. »
En fait, la mise à jour a Cette vulnérabilité a été appliquée aux appareils qui démarrent à la fois Windows et Linux. Cela inclut non seulement les appareils à double démarrage, mais également les appareils Windows qui peuvent démarrer Linux à partir d’une image ISO, d’une clé USB ou d’un support optique. De plus, de nombreux systèmes concernés exécutent des versions Linux récemment publiées, notamment Ubuntu 24.04 et Debian 12.6.0.
Et maintenant ?
Microsoft gardant le silence radio, les personnes concernées par le problème ont été obligées de trouver leurs propres solutions. Une option consiste à accéder à leur panneau EFI et à désactiver le démarrage sécurisé. En fonction des besoins de sécurité de l’utilisateur, cette option peut ne pas être acceptable. Une meilleure option à court terme consiste à supprimer le SBAT que Microsoft a publié mardi dernier. Cela signifie que les utilisateurs bénéficieront toujours de certains des avantages du démarrage sécurisé même s’ils restent vulnérables aux attaques qui exploitent CVE-2022-2601. Les étapes de cette solution sont décrites ici (merci à manutheeng pour la référence).
Les étapes spécifiques sont les suivantes :
1. Désactiver le démarrage sécurisé
2. Connectez-vous à votre compte d’utilisateur Ubuntu et ouvrez un terminal
3. Supprimez la politique SBAT avec :Code: Tout sélectionner
sudo mokutil –set-sbat-policy supprimer
4. Redémarrez votre PC et reconnectez-vous à Ubuntu pour mettre à jour la politique SBAT
5. Redémarrez puis réactivez le démarrage sécurisé dans votre BIOS.
Cet incident est le dernier en date à souligner le désordre qu’est devenu Secure Boot, ou qu’il a peut-être toujours été. Au cours des 18 derniers mois, les chercheurs ont découvert au moins quatre vulnérabilités qui peuvent être exploitées pour neutraliser complètement le mécanisme de sécurité. Le dernier exemple en date était le résultat de clés de test utilisées pour authentifier Secure Boot sur environ 500 modèles d’appareils. Les clés étaient marquées de manière visible de la mention « DO NOT TRUST » (Ne pas faire confiance).
« En fin de compte, même si Secure Boot rend le démarrage de Windows plus sûr, il semble comporter un nombre croissant de failles qui le rendent moins sûr qu’il ne le devrait », a déclaré Will Dormann, analyste senior des vulnérabilités chez Analygence, une société de sécurité. « SecureBoot est compliqué dans la mesure où il n’est pas réservé à Microsoft, même s’ils détiennent les clés du royaume. Toute vulnérabilité dans un composant SecureBoot peut affecter un système Windows uniquement compatible SecureBoot. En tant que tel, Microsoft doit traiter/bloquer les éléments vulnérables. »