Vulnérabilité dans le pilote NTFS de GRUB2 permettant l'exécution de code et le contournement de UEFI Secure Boot

Une vulnérabilité a été découverte dans le pilote gérant le système de fichiers NTFS dans le chargeur GRUB2 (CVE-2023-4692), permettant l'exécution de code personnalisé au niveau du chargeur lorsqu'il interagit avec une image de système de fichiers spécialement conçue. Cette vulnérabilité peut être exploitée pour contourner le mécanisme de vérification du démarrage sécurisé UEFI.

La vulnérabilité est causée par une erreur dans le code d'analyse de l'attribut NTFS « $ATTRIBUTE_LIST » (grub-core/fs/ntfs.c), qui peut être utilisé pour écrire des informations contrôlées par l'utilisateur dans une zone mémoire en dehors du tampon alloué. Lors du traitement d'une image NTFS soigneusement conçue, un dépassement de tampon entraîne l'écrasement d'une partie de la mémoire de GRUB et, dans certaines conditions, endommage la mémoire du firmware UEFI, permettant potentiellement l'exécution de code au niveau du chargeur ou du firmware.

De plus, une autre vulnérabilité a également été découverte dans le pilote NTFS de GRUB2 (CVE-2023-4693), permettant de lire le contenu d'une zone mémoire arbitraire lors de l'analyse de l'attribut « $DATA » dans une image NTFS spécialement formatée. Entre autres, cette vulnérabilité permet d'extraire des données confidentielles mises en cache en mémoire ou de déterminer les valeurs des variables EFI.

Les problèmes ont pour l'instant été résolus uniquement sous forme de patch. Le statut de la correction des vulnérabilités dans les distributions peut être évalué sur ces pages : Debian, Ubuntu, SUSE, RHEL, Fedora. Pour résoudre les problèmes dans GRUB2, il ne suffit pas de mettre à jour le paquet, il est également nécessaire de générer de nouvelles signatures numériques internes et de mettre à jour les installateurs, les chargeurs, les paquets du noyau, les firmwares fwupd et la couche shim.

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 de la 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 de la liste des certificats révoqués UEFI (dbx), mais se fait au niveau du remplacement de la clé interne pour la création des signatures et la mise à jour de GRUB2, shim et d'autres artefacts de démarrage fournis par les distributions. Avant l'implémentation de SBAT, la mise à jour de la liste des certificats révoqués (dbx, UEFI Revocation List) était une condition obligée pour le blocage complet d'une vulnérabilité, car un attaquant, quel que soit le système d'exploitation utilisé, pouvait compromettre UEFI Secure Boot via le démarrage.

Source : opennet.ru