Vulnérabilité dans le pilote NTFS de GRUB2, permettant l'exécution de code et contournant le démarrage sécurisé UEFI

Une vulnérabilité (CVE-2023-4692) a été identifiée dans le pilote prenant en charge le système de fichiers NTFS du chargeur de démarrage GRUB2. Cette vulnérabilité permet l'exécution de code personnalisé au niveau du chargeur de démarrage lors de l'accès à une image système de fichiers spécialement conçue. Elle peut être exploitée pour contourner le mécanisme de démarrage sécurisé UEFI.

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

Par ailleurs, une autre vulnérabilité (CVE-2023-4693) a été découverte dans le pilote NTFS de GRUB2. Cette vulnérabilité permet la lecture de données arbitraires en mémoire lors de l'analyse de l'attribut « $DATA » dans une image NTFS spécialement conçue. Elle permet notamment l'extraction de données sensibles mises en cache en mémoire ou la détermination des valeurs des variables EFI.

Jusqu'à présent, ces problèmes n'ont été résolus que par des correctifs. L'état des correctifs de vulnérabilité dans les distributions peut être consulté sur ces pages : Debian, UbuntuSUSE, RHEL, Fedora. La résolution des problèmes liés à GRUB2 ne se limite pas à la mise à jour du paquet ; elle nécessite également la génération de nouvelles signatures numériques internes et la mise à jour des installateurs, des chargeurs de démarrage, des paquets du noyau, du firmware fwupd et de la couche shim.

Dans la plupart LinuxLes distributions compatibles avec le démarrage sécurisé UEFI utilisent une petite couche d'interruption, signée numériquement par Microsoft. Cette couche vérifie GRUB2 à l'aide de son propre certificat, dispensant ainsi les développeurs de distributions d'informer Microsoft de chaque mise à jour du noyau et de GRUB. Des vulnérabilités dans GRUB2 permettent l'exécution de code arbitraire après la vérification réussie de la couche d'interruption, mais avant le démarrage du système d'exploitation. Cela permet à des attaquants de rompre la chaîne de confiance lorsque le démarrage sécurisé est activé et de prendre le contrôle total du processus de démarrage ultérieur, par exemple pour démarrer un autre système d'exploitation, modifier des composants du système d'exploitation ou 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 la prise en charge est implémentée pour GRUB2, shim et fwupd dans la plupart des distributions populaires. LinuxSBAT a été développé en collaboration avec Microsoft et consiste à ajouter des métadonnées aux fichiers exécutables des composants UEFI, notamment 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 les listes de composants autorisés ou interdits pour le démarrage sécurisé UEFI.

SBAT permet de bloquer l'utilisation des signatures numériques pour les numéros de version de composants individuels sans avoir à révoquer les clés de démarrage sécurisé. Le blocage des vulnérabilités via SBAT ne nécessite pas l'utilisation de la liste de révocation des certificats UEFI (dbx), mais s'effectue au niveau du remplacement de la clé interne de génération des signatures et de la mise à jour de GRUB2, du shim et des autres artefacts de démarrage fournis par les distributions. Avant l'introduction de SBAT, la mise à jour de la liste de révocation UEFI (dbx) était une condition indispensable pour bloquer complètement la vulnérabilité, car un attaquant, quel que soit le système d'exploitation utilisé, pouvait exploiter la clé de démarrage pour compromettre le démarrage sécurisé UEFI.

Source: opennet.ru