Vulnérabilités non corrigibles dans GRUB2 permettant de contourner UEFI Secure Boot

Des informations sur 8 vulnérabilités dans le chargeur GRUB2 ont été révélées, permettant de contourner le mécanisme UEFI Secure Boot et de lancer du code non vérifié, par exemple, d'injecter un logiciel malveillant fonctionnant au niveau du chargeur ou du noyau.

Rappelons qu'une petite couche shim, signée numériquement par Microsoft, est utilisée pour le démarrage sécurisé vérifié dans le mode UEFI Secure Boot sur la plupart des distributions Linux. Cette couche vérifie GRUB2 avec son 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'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'insérant 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 pour 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.

Comme pour la vulnérabilité BootHole de l'année dernière, mettre à jour le chargeur ne suffit pas à bloquer le problème, car un attaquant, quel que soit le système d'exploitation utilisé, peut compromettre UEFI Secure Boot en utilisant un support de démarrage avec une ancienne version vulnérable de GRUB2, signée numériquement. Le problème ne peut être résolu que par la mise à jour de la liste des certificats révoqués (dbx, UEFI Revocation List), mais dans ce cas, la possibilité d'utiliser d'anciens supports d'installation pour Linux sera perdue.

Sur les systèmes dont le firmware a mis à jour la liste des certificats révoqués, en mode UEFI Secure Boot, seules les versions mises à jour des distributions Linux pourront être chargées. Les distributions devront mettre à jour les installateurs, les chargeurs, les paquets du noyau, les firmwares fwupd et la couche shim, en générant pour eux de nouvelles signatures numériques. Les utilisateurs devront mettre à jour les images d'installation et d'autres supports de démarrage, ainsi que charger la liste des certificats révoqués (dbx) dans le firmware UEFI. Avant la mise à jour du dbx dans l’UEFI, le système reste vulnérable, quelle que soit l’installation des mises à jour dans le système d'exploitation. L'état de l'élimination des vulnérabilités peut être évalué sur ces pages : Ubuntu, SUSE, RHEL, Debian.

Pour résoudre les problèmes liés à la diffusion de certificats révoqués, il est prévu d'utiliser à l'avenir le mécanisme SBAT (UEFI Secure Boot Advanced Targeting), dont la prise en charge a été mise en œuvre pour GRUB2, shim et fwupd, et qui sera utilisé à partir des prochaines mises à jour au lieu de la fonctionnalité fournie par le paquet dbxtool. SBAT a été développé en collaboration avec Microsoft et implique l'ajout de nouvelles métadonnées dans les 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 électroniquement et peuvent être incluses dans des listes de composants autorisés ou interdits pour UEFI Secure Boot. Ainsi, SBAT permettra de manipuler les numéros de version des composants lors d'un retrait, sans la nécessité de régénérer les clés pour Secure Boot et sans former de nouvelles signatures pour le noyau, shim, grub2 et fwupd.

Vulnérabilités identifiées :

• CVE-2020-14372 — grâce à la commande acpi dans GRUB2, un utilisateur privilégié du système local peut charger des tables ACPI modifiées en plaçant le SSDT (Secondary System Description Table) dans le répertoire /boot/efi et en modifiant les paramètres dans grub.cfg. Malgré l'activation du mode Secure Boot, le SSDT proposé sera exécuté par le noyau et peut être utilisé pour désactiver la protection LockDown, qui bloque les voies de contournement de UEFI Secure Boot. En conséquence, l'attaquant peut réussir à charger son module noyau ou à exécuter du code via le mécanisme kexec, sans vérification de la signature numérique.
• CVE-2020-25632 — accès à une zone mémoire déjà libérée (use-after-free) dans l'implémentation de la commande rmmod, se manifestant lors de la tentative de déchargement de tout module sans prendre en compte ses dépendances associées. La vulnérabilité permet la création d'un exploit qui peut conduire à l'exécution de code en contournant la vérification de Secure Boot.
• CVE-2020-25647 — écriture hors limites dans la fonction grub_usb_device_initialize(), appelée lors de l'initialisation des périphériques USB. Le problème peut être exploité via la connexion d'un périphérique USB spécialement préparé, fournissant des paramètres dont la taille ne correspond pas à celle du tampon alloué pour les structures USB. L'attaquant peut réussir à exécuter du code non vérifié dans Secure Boot par le biais de manipulations avec les périphériques USB.
• CVE-2020-27749 — débordement de tampon dans la fonction grub_parser_split_cmdline(), pouvant être déclenché par la spécification de variables dans la ligne de commande GRUB2 dont la taille dépasse 1 Ko. Cette vulnérabilité permet l'exécution de code en contournant le Secure Boot.
• CVE-2020-27779 — la commande cutmem permet à un attaquant de supprimer une plage d'adresses de la mémoire pour contourner le Secure Boot.
• CVE-2021-3418 — des modifications dans shim_lock ont créé un vecteur supplémentaire pour exploiter la vulnérabilité de l'année dernière CVE-2020-15705. Lors de l'installation dans dbx d'un certificat utilisé pour signer GRUB2, GRUB2 permettait de charger n'importe quel noyau directement sans vérification de la signature.
• CVE-2021-20225 — possibilité d'écrire des données au-delà du tampon lors de l'exécution de commandes avec un nombre très élevé d'options.
• CVE-2021-20233 — possibilité d'écrire des données en dehors du tampon en raison d'un calcul incorrect de la taille du tampon lors de l'utilisation de guillemets. Lors du calcul de la taille, il était supposé que trois caractères étaient nécessaires pour échapper une apostrophe, alors qu'en réalité il en fallait quatre.

Source : opennet.ru