{"id":99320,"date":"2021-03-03T16:22:39","date_gmt":"2021-03-03T14:22:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2021-03-03T16:22:39","modified_gmt":"2021-03-03T14:22:39","slug":"trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/trudnoustranimye-uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Vuln\u00e9rabilit\u00e9s non corrigibles dans GRUB2 permettant de contourner UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Des informations sur 8 vuln\u00e9rabilit\u00e9s dans le chargeur GRUB2 ont \u00e9t\u00e9 r\u00e9v\u00e9l\u00e9es, permettant de contourner le m\u00e9canisme UEFI Secure Boot et de lancer du code non v\u00e9rifi\u00e9, par exemple, d'injecter un logiciel malveillant fonctionnant au niveau du chargeur ou du noyau. <\/p>\n
Rappelons qu'une petite couche shim, sign\u00e9e num\u00e9riquement par Microsoft, est utilis\u00e9e pour le d\u00e9marrage s\u00e9curis\u00e9 v\u00e9rifi\u00e9 dans le mode UEFI Secure Boot sur la plupart des distributions Linux. Cette couche v\u00e9rifie GRUB2 avec son certificat, ce qui permet aux d\u00e9veloppeurs de distributions de ne pas signer chaque mise \u00e0 jour du noyau et de GRUB chez Microsoft. Les vuln\u00e9rabilit\u00e9s dans GRUB2 permettent d'ex\u00e9cuter son propre code apr\u00e8s la v\u00e9rification r\u00e9ussie de shim, mais avant le chargement du syst\u00e8me d'exploitation, en s'ins\u00e9rant dans la cha\u00eene de confiance en mode Secure Boot actif et en obtenant un contr\u00f4le total sur le processus de d\u00e9marrage ult\u00e9rieur, y compris pour le chargement d'un autre syst\u00e8me d'exploitation, la modification des composants du syst\u00e8me d'exploitation et le contournement de la protection Lockdown. <\/p>\n
Comme pour la vuln\u00e9rabilit\u00e9 BootHole de l'ann\u00e9e derni\u00e8re, mettre \u00e0 jour le chargeur ne suffit pas \u00e0 bloquer le probl\u00e8me, car un attaquant, quel que soit le syst\u00e8me d'exploitation utilis\u00e9, peut compromettre UEFI Secure Boot en utilisant un support de d\u00e9marrage avec une ancienne version vuln\u00e9rable de GRUB2, sign\u00e9e num\u00e9riquement. Le probl\u00e8me ne peut \u00eatre r\u00e9solu que par la mise \u00e0 jour de la liste des certificats r\u00e9voqu\u00e9s (dbx, UEFI Revocation List), mais dans ce cas, la possibilit\u00e9 d'utiliser d'anciens supports d'installation pour Linux sera perdue. <\/p>\n
Sur les syst\u00e8mes dont le firmware a mis \u00e0 jour la liste des certificats r\u00e9voqu\u00e9s, en mode UEFI Secure Boot, seules les versions mises \u00e0 jour des distributions Linux pourront \u00eatre charg\u00e9es. Les distributions devront mettre \u00e0 jour les installateurs, les chargeurs, les paquets du noyau, les firmwares fwupd et la couche shim, en g\u00e9n\u00e9rant pour eux de nouvelles signatures num\u00e9riques. Les utilisateurs devront mettre \u00e0 jour les images d'installation et d'autres supports de d\u00e9marrage, ainsi que charger la liste des certificats r\u00e9voqu\u00e9s (dbx) dans le firmware UEFI. Avant la mise \u00e0 jour du dbx dans l\u2019UEFI, le syst\u00e8me reste vuln\u00e9rable, quelle que soit l\u2019installation des mises \u00e0 jour dans le syst\u00e8me d'exploitation. L'\u00e9tat de l'\u00e9limination des vuln\u00e9rabilit\u00e9s peut \u00eatre \u00e9valu\u00e9 sur ces pages : Ubuntu, SUSE, RHEL, Debian. <\/p>\n
Pour r\u00e9soudre les probl\u00e8mes li\u00e9s \u00e0 la diffusion de certificats r\u00e9voqu\u00e9s, il est pr\u00e9vu d'utiliser \u00e0 l'avenir le m\u00e9canisme SBAT (UEFI Secure Boot Advanced Targeting), dont la prise en charge a \u00e9t\u00e9 mise en \u0153uvre pour GRUB2, shim et fwupd, et qui sera utilis\u00e9 \u00e0 partir des prochaines mises \u00e0 jour au lieu de la fonctionnalit\u00e9 fournie par le paquet dbxtool. SBAT a \u00e9t\u00e9 d\u00e9velopp\u00e9 en collaboration avec Microsoft et implique l'ajout de nouvelles m\u00e9tadonn\u00e9es dans les fichiers ex\u00e9cutables des composants UEFI, incluant des informations sur le fabricant, le produit, le composant et la version. Ces m\u00e9tadonn\u00e9es sont sign\u00e9es \u00e9lectroniquement et peuvent \u00eatre incluses dans des listes de composants autoris\u00e9s ou interdits pour UEFI Secure Boot. Ainsi, SBAT permettra de manipuler les num\u00e9ros de version des composants lors d'un retrait, sans la n\u00e9cessit\u00e9 de r\u00e9g\u00e9n\u00e9rer les cl\u00e9s pour Secure Boot et sans former de nouvelles signatures pour le noyau, shim, grub2 et fwupd. <\/p>\n
CVE-2020-14372 \u2014 \u00c0 l'aide de la commande acpi dans GRUB2, un utilisateur privil\u00e9gi\u00e9 du syst\u00e8me local peut charger des tables ACPI modifi\u00e9es en pla\u00e7ant le SSDT (Secondary System Description Table) dans le r\u00e9pertoire \/boot\/efi et en modifiant les param\u00e8tres dans grub.cfg. Malgr\u00e9 l'activit\u00e9 du mode Secure Boot, le SSDT propos\u00e9 sera ex\u00e9cut\u00e9 par le noyau et peut \u00eatre utilis\u00e9 pour d\u00e9sactiver la protection LockDown, qui bloque les chemins de contournement du d\u00e9marrage s\u00e9curis\u00e9 UEFI. En fin de compte, l'attaquant peut r\u00e9ussir \u00e0 charger son module noyau ou \u00e0 ex\u00e9cuter du code via le m\u00e9canisme kexec, sans v\u00e9rification de la signature num\u00e9rique.\n
CVE-2020-25632 \u2014 Un acc\u00e8s \u00e0 une zone m\u00e9moire d\u00e9j\u00e0 lib\u00e9r\u00e9e (use-after-free) dans l'impl\u00e9mentation de la commande rmmod se manifeste lors d'une tentative de d\u00e9chargement de tout module sans tenir compte des d\u00e9pendances associ\u00e9es. Cette vuln\u00e9rabilit\u00e9 ne pr\u00e9vient pas la cr\u00e9ation d'un exploit qui pourrait entra\u00eener l'ex\u00e9cution de code en contournant la v\u00e9rification de Secure Boot.\n
CVE-2020-25647 \u2014 \u00c9criture en dehors des limites du tampon dans la fonction grub_usb_device_initialize(), appel\u00e9e lors de l'initialisation des p\u00e9riph\u00e9riques USB. Le probl\u00e8me peut \u00eatre exploit\u00e9 en connectant un p\u00e9riph\u00e9rique USB sp\u00e9cialement con\u00e7u, fournissant des param\u00e8tres dont la taille ne correspond pas \u00e0 celle du tampon allou\u00e9 pour les structures USB. L'attaquant peut r\u00e9ussir \u00e0 ex\u00e9cuter du code non v\u00e9rifi\u00e9 dans Secure Boot en manipulant des p\u00e9riph\u00e9riques USB.\n
CVE-2020-27749 \u2014 D\u00e9bordement de tampon dans la fonction grub_parser_split_cmdline(), qui peut \u00eatre provoqu\u00e9 par la sp\u00e9cification de variables sur la ligne de commande GRUB2 ayant une taille sup\u00e9rieure \u00e0 1 Ko. La vuln\u00e9rabilit\u00e9 permet d'ex\u00e9cuter du code en contournant Secure Boot.\n
CVE-2020-27779 \u2014 La commande cutmem permet \u00e0 un attaquant de supprimer une plage d'adresses de la m\u00e9moire afin de contourner Secure Boot.\n
CVE-2021-3418 \u2014 Des modifications dans shim_lock ont cr\u00e9\u00e9 un vecteur suppl\u00e9mentaire pour exploiter la vuln\u00e9rabilit\u00e9 de l'ann\u00e9e derni\u00e8re, CVE-2020-15705. Lors de l\u2019installation d'un certificat dans dbx utilis\u00e9 pour signer GRUB2, GRUB2 a permis de charger n'importe quel noyau directement sans v\u00e9rifier la signature.\n
CVE-2021-20225 \u2014 Une possibilit\u00e9 d'\u00e9criture de donn\u00e9es en dehors des limites du tampon lors de l'ex\u00e9cution de commandes avec un nombre tr\u00e8s \u00e9lev\u00e9 d'options.\n
CVE-2021-20233 \u2014 Une possibilit\u00e9 d'\u00e9criture de donn\u00e9es au-del\u00e0 des limites 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, on supposait que l'\u00e9chappement d'une apostrophe n\u00e9cessitait trois caract\u00e8res, alors qu'en r\u00e9alit\u00e9, il en faut quatre. <\/ul>\n