Deux vulnérabilités dans GRUB2 permettant de contourner la protection UEFI Secure Boot

Des informations ont été révélées concernant deux vulnérabilités dans le chargeur GRUB2, qui pourraient permettre l'exécution de code en utilisant des polices spécialement conçues et le traitement de certaines séquences Unicode. Ces vulnérabilités pourraient être exploitées pour contourner le mécanisme de vérification de l'amorçage UEFI Secure Boot.

Vulnérabilités identifiées :

• CVE-2022-2601 — débordement de tampon dans la fonction grub_font_construct_glyph() lors du traitement de polices spécialement conçues au format pf2, résultant d'une mauvaise estimation du paramètre max_glyph_size et de l'allocation d'un espace mémoire notoirement inférieur à ce qui est nécessaire pour contenir les glyphes.
• CVE-2022-3775 — écriture hors de l'espace mémoire alloué lors du rendu de certaines séquences Unicode avec une police spécialement conçue. Ce problème est présent dans le code de traitement des polices et est causé par un manque de vérifications appropriées de la correspondance entre la largeur et la hauteur du glyphe et la taille de la bitmap existante. Un attaquant peut formuler une entrée de façon à provoquer un écriture des données à la limite de l'espace tampon alloué. Il est à noter que malgré la complexité de l'exploitation de cette vulnérabilité, l'atteinte d'une exécution de code n'est pas exclue.

Un correctif a été publié sous la forme d'un patch. L'état de correction des vulnérabilités dans les distributions peut être évalué sur ces pages : Ubuntu, SUSE, RHEL, Fedora, Debian. Pour résoudre les problèmes dans GRUB2, il ne suffit pas simplement de mettre à jour le package, il faudra également créer de nouvelles signatures numériques internes et mettre à jour les installateurs, les chargeurs, les packages du noyau, les firmwares fwupd et le shim.

Dans la plupart des distributions Linux, une petite couche shim, signée numériquement par Microsoft, est utilisée pour l'amorçage vérifié en mode UEFI Secure Boot. Cette couche vérifie GRUB2 avec son propre certificat, ce qui permet aux développeurs de distributions de ne pas signer chaque mise à jour du noyau et de GRUB chez Microsoft. Les vulnérabilités dans GRUB2 permettent d'atteindre l'exécution de son code à un stade 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 obtenant un contrôle total sur le processus de démarrage ultérieur, y compris le chargement d'un autre système d'exploitation, la modification des composants du système d'exploitation et le contournement de 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