21 vulnérabilité détectée dans le chargeur GRUB2

Des informations concernant 21 vulnérabilités dans le chargeur GRUB2 ont été publiées, dont la majorité entraînent un débordement de tampon et peuvent être exploitées pour contourner le mécanisme de vérification du démarrage sécurisé UEFI. Les problèmes ont seulement été corrigés sous forme de patch pour l'instant. L'état de la correction des vulnérabilités dans les distributions peut être évalué sur les pages suivantes : Debian, Ubuntu, SUSE, RHEL, Fedora. Pour remédier aux problèmes dans GRUB2, il ne suffit pas de mettre à jour le paquet ; il faut également générer de nouvelles signatures numériques internes et procéder à la mise à jour des installateurs, des chargeurs, des paquets de noyau, des firmwares fwupd et de la couche shim.

Vulnérabilités identifiées :

  • CVE-2024-45774 : écriture en dehors du tampon lors du traitement d'images JPEG spécialement conçues.
  • CVE-2024-45776, CVE-2024-45777 : débordements d'entier lors de la lecture de fichiers mo spécialement formatés, entraînant une écriture en dehors du tampon.
  • CVE-2024-45778, CVE-2024-45779 : débordements d'entier lors du traitement d'un système de fichiers BFS corrompu, entraînant un débordement de tampon.
  • CVE-2024-45780 : débordement d'entier lors du traitement d'archives tar spécialement formatées, entraînant une écriture en dehors du tampon.
  • CVE-2024-45781, CVE-2025-0677 : débordements de tampon lors du traitement d'un système de fichiers UFS corrompu.
  • CVE-2024-45782, CVE-2025-1125 : débordements de tampon lors du montage d'une partition HFS spécialement formatée.
  • CVE-2025-0622 : accès à la mémoire après libération lors de la manipulation de modules, pouvant conduire à l'exécution de code malveillant.
  • CVE-2025-0624 : débordement de tampon lors d'un démarrage réseau.
  • CVE-2025-0678 : débordements de tampon lors du traitement d'un système de fichiers Squash4 corrompu.
  • CVE-2025-0684 : débordements de tampon lors de la manipulation de liens symboliques dans le système de fichiers Reiserfs.
  • CVE-2025-0685 : débordements de tampon lors de la manipulation de liens symboliques dans le système de fichiers JFS.
  • CVE-2025-0685 : débordements de tampon lors de la manipulation de liens symboliques dans le système de fichiers ROMFS.
  • CVE-2025-0689 : débordements de tampon lors du traitement d'une partition UDF spécialement modifiée.
  • CVE-2025-0690 : débordements de tampon lors de la réception de données spécialement formatées depuis le clavier.
  • CVE-2025-1118 : contournement du mode d'isolement Lockdown et extraction de contenu mémoire arbitraire via l'exécution de la commande dump.
  • CVE-2024-45775 : absence de vérification du code d'erreur lors de l'allocation de mémoire lors du traitement des arguments transmis, ce qui peut entraîner des corruptions de données IVT (Interrupt Vector Table).
  • CVE-2024-45783 : accès par un pointeur nul lors du montage d'un système de fichiers HFS+ incorrect.

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