Rien d'étrange, zéro drame ... Mais un autre a été découvert vulnérabilité, CVE-2020-10713, qui affecte le chargeur de démarrage GRUB2 et le démarrage sécurisé. Une publication de l'équipe de recherche Eclypsium est celle qui a été à l'origine de cette découverte et qu'ils ont baptisée BootHole. Même Microsoft a publié une entrée sur son portail de sécurité en mettant en garde et affirmant qu'il existe une solution compliquée pour le moment.
standole Il s'agit d'une vulnérabilité de débordement de tampon qui affecte des milliards d'appareils avec GRUB2 et même d'autres sans GRUB2 qui utilisent Secure Boot comme Windows. Dans la classification du système CVSS, il a été noté 8.2 sur 10, ce qui signifie qu'il s'agit d'un risque élevé. Et c'est qu'un attaquant pourrait en profiter pour être en mesure d'exécuter du code arbitraire (y compris des logiciels malveillants) introduit pendant le processus de démarrage, même avec Secure Boot activé.
si dispositivos les réseaux, les serveurs, les postes de travail, les ordinateurs de bureau et les ordinateurs portables, ainsi que d'autres appareils tels que les SBC, certains appareils mobiles, les appareils IoT, etc., seraient affectés.
De plus, selon Eclypsium, ce sera compliqué à atténuer et il faudra du temps pour trouver une solution. Cela nécessitera un examen approfondi des chargeurs de démarrage et les fournisseurs devraient publier de nouvelles versions de chargeurs de démarrage signés par UEFI CA. Il faudra des efforts coordonnés entre les développeurs de la communauté open source et collaborative de Microsoft et les autres propriétaires de systèmes concernés pour faire tomber BootHole.
En fait, ils ont fait un Liste des tâches pour pouvoir réparer BootHole dans GRUB2 et vous avez besoin de:
- Patch pour mettre à jour GRUB2 et éliminer la vulnérabilité.
- Que les développeurs de distributions Linux et d'autres fournisseurs publient les mises à jour pour leurs utilisateurs. Tant au niveau de GRUB2, des installateurs et des cales.
- Les nouvelles cales doivent être signées par l'autorité de certification Microsoft UEFI pour des tiers.
- Les administrateurs de systèmes d'exploitation devront évidemment se mettre à jour. Mais il doit inclure à la fois le système installé, les images du programme d'installation et également le support de récupération ou de démarrage qu'ils ont créé.
- La liste de révocation UEFI (dbx) devra également être mise à jour dans le micrologiciel de chaque système affecté pour empêcher l'exécution de code pendant le démarrage.
Le pire, c'est qu'en ce qui concerne le firmware, il faut être prudent et faire attention de ne pas se retrouver avec des problèmes et que les ordinateurs restent en mode brique.
À l'heure actuelle, des entreprises telles que Red Hat, HP, Debian, SUSE, Canonical, Oracle, Microsoft, VMWare, Citrix, UEFI Security Response Team et OEM, ainsi que des fournisseurs de logiciels, ils travaillent déjà à le résoudre. Cependant, il faudra attendre de voir les premiers patchs.
MISE À JOUR
Mais sous-estimer l'efficacité des développeurs et de la communauté serait stupide. Déjà il y a plusieurs patchs candidats pour l'atténuer qui proviennent d'entreprises comme Red Hat, Canonical, etc. Ils ont signalé ce problème comme une priorité absolue et il porte ses fruits.
Le problème? Le problème est que ces correctifs posent des problèmes supplémentaires. Cela me rappelle ce qui s'est passé avec les patchs Metldown et Spectre, que parfois le remède est pire que la maladie ...