6 vulnérabilités dans le chargeur GRUB2 permettant de contourner le démarrage sécurisé UEFI

Un ensemble de correctifs a été publié pour remédier à 6 vulnérabilités dans le chargeur GRUB2, dont la plupart entraînent un accès à la mémoire après sa libération (use-after-free). Les problèmes potentiellement identifiés peuvent être exploités pour contourner le mécanisme de vérification du démarrage sécurisé UEFI. L'état de la correction des vulnérabilités dans les distributions peut être évalué sur ces pages : Debian, Ubuntu, SUSE, RHEL, Arch et Fedora. Pour résoudre les problèmes dans GRUB2, il ne suffit pas de mettre à jour le paquet, il est également nécessaire de créer de nouvelles signatures numériques internes et de mettre à jour les installateurs, les chargeurs, les paquets du noyau, les firmwares fwupd et le module shim.

Vulnérabilités identifiées :

  • CVE-2025-61661 — dépassement de tampon dans la fonction grub_usb_get_string(), qui peut être exploitée lors du traitement de chaînes en codage UTF-8 et UTF-16 transmises lors de la connexion de périphériques USB. Le problème est causé par le fait que le tampon était alloué en fonction de la taille de la chaîne spécifiée dans le premier message du périphérique USB, tandis que la taille lors de la conversion de codage était calculée sur la base des opérations de lecture ultérieures à partir du périphérique USB. Par conséquent, un périphérique USB modifié pouvant initialement retourner une valeur de taille inférieure peut être utilisé pour l'attaque.
  • CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 — absence de nettoyage des gestionnaires de commandes «normal», «normal_exit», «net_set_vlan» et «gettext» lors du déchargement des modules «normal», «net» et «gettext», créant des conditions pour un accès à la mémoire après sa libération (use-after-free) si les commandes mentionnées sont exécutées après le déchargement des modules correspondants. Des vulnérabilités similaires ont également été trouvées pour les commandes «functional_test» et «all_functional_test», mais elles n'ont pas reçu d'identifiants CVE, car ces commandes font partie de la bibliothèque de tests et ne devraient pas être incluses dans les builds de production.
  • CVE-2025-54771 — erreur lors du comptage des références sur les structures «fs» dans la fonction grub_file_close(), entraînant un accès à la mémoire après sa libération (use-after-free).

Dans la plupart des distributions Linux, un petit intermédiaire appelé shim, signé numériquement par Microsoft, est utilisé pour le démarrage sécurisé en mode UEFI. Cet intermédiaire vérifie GRUB2 avec son propre certificat, ce qui permet aux développeurs de distributions de ne pas avoir à certifier chaque mise à jour du noyau et de GRUB auprès de Microsoft. Les vulnérabilités de GRUB2 permettent d'exécuter son propre code après la vérification réussie de shim, mais avant le chargement du système d'exploitation, en s'infiltrant dans la chaîne de confiance en mode Secure Boot actif et en prenant le contrôle total du processus de démarrage, par exemple pour charger un autre système d'exploitation, modifier des composants du système d'exploitation et contourner la protection Lockdown.

Pour bloquer la vulnérabilité sans révoquer la signature numérique, les distributions peuvent utiliser le mécanisme SBAT (UEFI Secure Boot Advanced Targeting), dont le support est mis en œuvre pour GRUB2, shim et fwupd dans la plupart des distributions Linux populaires. SBAT a été développé en collaboration avec Microsoft et implique l'ajout de métadonnées supplémentaires aux fichiers exécutables des composants UEFI, incluant des informations sur le fabricant, le produit, le composant et la version. Ces métadonnées sont signées numériquement et peuvent être incluses séparément dans des listes de composants autorisés ou interdits pour le démarrage sécurisé UEFI.

SBAT permet de bloquer l'utilisation d'une signature numérique pour des numéros de version spécifiques des composants sans avoir à révoquer les clés pour le Secure Boot. Le blocage des vulnérabilités via SBAT ne nécessite pas l'utilisation d'une liste de certificats révoqués UEFI (dbx), mais se réalise au niveau du remplacement de la clé interne pour la génération des signatures et la mise à jour de GRUB2, shim et d'autres artefacts de démarrage fournis par les distributions. Avant l'implémentation du SBAT, la mise à jour de la liste des certificats révoqués (dbx, UEFI Revocation List) était une condition préalable pour bloquer complètement la vulnérabilité, car un attaquant, quelle que soit la version du système d'exploitation utilisée, pouvait compromettre le démarrage sécurisé UEFI en utilisant un support de démarrage avec une ancienne version vulnérable de GRUB2 signée numériquement.

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster