Getty Images
Le mardi dernier, de nombreux utilisateurs de Linux—beaucoup utilisant des distributions mises à jour cette année—ont commencé à signaler que leurs appareils ne parvenaient pas à démarrer. À la place, ils recevaient un message d’erreur cryptique incluant la phrase : « Quelque chose a sérieusement mal tourné. »
La cause : une mise à jour que Microsoft a publiée dans le cadre de son patch mensuel. Cette mise à jour visait à corriger une vulnérabilité vieille de deux ans dans GRUB, un chargeur d’amorçage open source utilisé pour démarrer de nombreux appareils Linux. Cette vulnérabilité, notée 8.6 sur 10 en termes de gravité, permettait aux pirates de contourner le démarrage sécurisé, la norme de l’industrie pour garantir que les appareils exécutant Windows ou d’autres systèmes d’exploitation ne chargent pas de firmware ou de logiciels malveillants lors du processus de démarrage. 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, anciennes et récentes, touchées
La mise à jour de mardi a rendu les appareils à double démarrage—ceux configurés pour exécuter à la fois Windows et Linux—incapables de démarrer sous Linux lorsque le démarrage sécurisé était activé. Lorsque les utilisateurs tentaient de charger Linux, ils recevaient le message : « Vérification des données SBAT de shim échouée : violation de la politique de sécurité. Quelque chose a sérieusement mal tourné : l’auto-vérification SBAT a échoué : violation de la politique de sécurité. » Peu après, les forums de soutien et de discussion ont été inondés de rapports concernant cette erreur.
« Notez que Windows dit que cette mise à jour ne s’applique pas aux systèmes en double démarrage Windows et Linux », a écrit une personne frustrée. « Ce n’est manifestement pas vrai, et cela dépend probablement de votre configuration système et de la distribution utilisée. Il semble que cela ait rendu certains chargeurs d’amorçage shim EFI Linux incompatibles avec les chargeurs d’amorçage EFI de Microcrap (c’est pourquoi changer de l’EFI de MS à ‘autre OS’ dans la configuration EFI fonctionne). Il semble que Mint ait 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 touchées. Microsoft n’a pas encore reconnu l’erreur publiquement, expliqué pourquoi elle n’a pas été détectée lors des tests, ou fourni des conseils techniques aux personnes affectées. Les représentants de l’entreprise n’ont pas répondu à un courriel demandant des explications.
Le bulletin de Microsoft concernant CVE-20220-2601 a expliqué que la mise à jour installerait un SBAT—un mécanisme Linux pour 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, le démarrage sécurisé sur les dispositifs Windows ne serait plus vulnérable aux attaques exploitant la vulnérabilité du package GRUB. Microsoft a assuré aux utilisateurs que leurs systèmes à double démarrage ne seraient pas affectés, bien qu’elle ait averti que les appareils exécutant des versions 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 », précisait le bulletin. « Vous constaterez peut-être que les ISO des anciennes distributions Linux ne démarrent pas. Si cela se produit, travaillez avec votre fournisseur Linux pour obtenir une mise à jour. »
En réalité, la mise à jour a été appliquée aux dispositifs démarrant à la fois sous Windows et Linux. Cela inclut non seulement les appareils à double démarrage, mais aussi les dispositifs Windows capables de démarrer Linux à partir d’une image ISO, d’une clé USB ou d’un support optique. De plus, beaucoup des systèmes affectés exécutent des versions récentes de Linux, y compris Ubuntu 24.04 et Debian 12.6.0.
Que faire maintenant ?
En l’absence de commentaires de Microsoft, ceux affectés par la panne ont été contraints de trouver leurs propres solutions. Une option consiste à accéder à leur panneau EFI et à désactiver le démarrage sécurisé. Selon les besoins en matière de sécurité de l’utilisateur, cette option peut ne pas être acceptable. Une meilleure option à court terme est de supprimer le SBAT que Microsoft a publié mardi dernier. Cela signifie que les utilisateurs bénéficieront toujours de certains avantages du démarrage sécurisé même s’ils demeurent vulnérables aux attaques exploitant CVE-2022-2601. Les étapes pour cette solution sont détaillées 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 utilisateur Ubuntu et ouvrez un terminal
3. Supprimez la politique SBAT avec :Code : Sélectionner tout
sudo mokutil –set-sbat-policy delete
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.
Ce problème souligne une fois de plus à quel point le démarrage sécurisé est devenu un casse-tête, ou l’a 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 ce mécanisme de sécurité. Le précédent incident significatif avait résulté de clés de test utilisées pour authentifier le démarrage sécurisé sur environ 500 modèles d’appareils. Les clés étaient clairement marquées du slogan « NE FAITES PAS CONFIANCE ».
« En fin de compte, bien que le démarrage sécurisé rende le démarrage de Windows plus sécurisé, il semble qu’il accumule de plus en plus de défauts qui le rendent pas tout à fait aussi sûr qu’il se devrait », a déclaré Will Dormann, analyste senior des vulnérabilités chez la société de sécurité Analygence. « Le démarrage sécurisé devient problématique dans la mesure où ce n’est pas qu’un simple problème de Microsoft, même s’ils ont les clés du royaume. Toute vulnérabilité dans un composant de démarrage sécurisé pourrait affecter un système Windows uniquement avec démarrage sécurisé. Ainsi, Microsoft doit traiter ou bloquer les éléments vulnérables. »
En tant que passionné de technologie et utilisateur de Linux, cet incident me rappelle que, malgré les avancées en matière de sécurité, le chemin reste semé d’embûches. Il est impératif que les entreprises, en particulier celles de l’envergure de Microsoft, prennent la responsabilité d’informer rapidement leurs utilisateurs et de remédier aux problèmes rencontrés.