{"id":104320,"date":"2022-06-08T15:36:43","date_gmt":"2022-06-08T13:36:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot"},"modified":"2022-06-08T15:36:43","modified_gmt":"2022-06-08T13:36:43","slug":"uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/uyazvimosti-v-grub2-pozvolyayushhie-obojti-uefi-secure-boot","title":{"rendered":"Vuln\u00e9rabilit\u00e9s dans GRUB2, permettant de contourner UEFI Secure Boot","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Le chargeur GRUB2 a corrig\u00e9 7 vuln\u00e9rabilit\u00e9s permettant de contourner le m\u00e9canisme UEFI Secure Boot et d'ex\u00e9cuter du code non v\u00e9rifi\u00e9, comme l'injection de logiciels malveillants fonctionnant au niveau du chargeur ou du noyau. De plus, une vuln\u00e9rabilit\u00e9 dans la couche shim a \u00e9galement \u00e9t\u00e9 signal\u00e9e, permettant de contourner UEFI Secure Boot. Ce groupe de vuln\u00e9rabilit\u00e9s a \u00e9t\u00e9 baptis\u00e9 Boothole 3, sur le mod\u00e8le de probl\u00e8mes similaires pr\u00e9c\u00e9demment identifi\u00e9s dans le chargeur. <\/p>\n
Pour r\u00e9soudre les probl\u00e8mes dans GRUB2 et shim, les distributions pourront utiliser le m\u00e9canisme SBAT (UEFI Secure Boot Advanced Targeting), dont le support est mis en \u0153uvre pour GRUB2, shim et fwupd. SBAT a \u00e9t\u00e9 d\u00e9velopp\u00e9 en collaboration avec Microsoft et implique l'ajout de m\u00e9tadonn\u00e9es suppl\u00e9mentaires aux 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 num\u00e9riquement et peuvent \u00eatre incluses s\u00e9par\u00e9ment dans les listes de composants autoris\u00e9s ou interdits pour UEFI Secure Boot. <\/p>\n
Dans la plupart des distributions Linux, une petite couche shim, sign\u00e9e num\u00e9riquement par Microsoft, est utilis\u00e9e pour l'amor\u00e7age v\u00e9rifi\u00e9 en mode UEFI Secure Boot. Cette couche v\u00e9rifie GRUB2 avec son propre 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'atteindre l'ex\u00e9cution de son code \u00e0 un stade apr\u00e8s la v\u00e9rification r\u00e9ussie de shim, mais avant le chargement du syst\u00e8me d'exploitation, en s'infiltrant 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 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
Pour corriger les probl\u00e8mes dans le chargeur, les distributions devront former de nouvelles signatures num\u00e9riques internes et mettre \u00e0 jour les installateurs, les chargeurs de d\u00e9marrage, les paquets de noyau, les mises \u00e0 jour fwupd et la couche shim. Avant l'impl\u00e9mentation de SBAT, la mise \u00e0 jour de la liste des certificats r\u00e9voqu\u00e9s (dbx, UEFI Revocation List) \u00e9tait une condition sine qua non pour bloquer enti\u00e8rement la vuln\u00e9rabilit\u00e9, car un attaquant, quel que soit le syst\u00e8me d'exploitation utilis\u00e9, pouvait compromettre UEFI Secure Boot en utilisant un support de d\u00e9marrage avec une ancienne version vuln\u00e9rable de GRUB2, sign\u00e9e num\u00e9riquement. <\/p>\n
Au lieu de r\u00e9voquer la signature, SBAT permet de bloquer son utilisation pour des num\u00e9ros de version sp\u00e9cifiques des composants sans avoir besoin de r\u00e9voquer des cl\u00e9s pour Secure Boot. Le blocage des vuln\u00e9rabilit\u00e9s via SBAT ne n\u00e9cessite pas l'utilisation de la liste des certificats r\u00e9voqu\u00e9s UEFI (dbx), mais s'effectue au niveau du remplacement de la cl\u00e9 interne pour la formation des signatures et la mise \u00e0 jour de GRUB2, shim et d'autres artefacts de d\u00e9marrage fournis par les distributions. Actuellement, le support de SBAT a d\u00e9j\u00e0 \u00e9t\u00e9 ajout\u00e9 dans la plupart des distributions Linux populaires. <\/p>\n
CVE-2021-3696, CVE-2021-3695 - d\u00e9bordement de tampon dans le tas lors du traitement d'images PNG sp\u00e9cialement con\u00e7ues, ce qui pourrait th\u00e9oriquement \u00eatre exploit\u00e9 pour ex\u00e9cuter du code malveillant et contourner UEFI Secure Boot. Il est not\u00e9 que le probl\u00e8me est difficile \u00e0 exploiter, car la cr\u00e9ation d'un exploit fonctionnel n\u00e9cessite la prise en compte d'un grand nombre de facteurs et des informations sur la disposition de la m\u00e9moire.\n
CVE-2021-3697 - d\u00e9bordement par sous-flot de tampon dans le code de traitement des images JPEG. L'exploitation du probl\u00e8me n\u00e9cessite des informations sur la disposition de la m\u00e9moire et est d'une complexit\u00e9 comparable \u00e0 celle du probl\u00e8me avec PNG (CVSS 7.5).\n
CVE-2022-28733 \u2014 d\u00e9bordement entier dans la fonction grub_net_recv_ip4_packets(), permettant d'influencer le param\u00e8tre rsm->total_len via l'envoi d'un paquet IP sp\u00e9cialement con\u00e7u. Ce probl\u00e8me est qualifi\u00e9 de vuln\u00e9rabilit\u00e9 la plus dangereuse de celles pr\u00e9sent\u00e9es (CVSS 8.1). Lorsqu'elle est exploit\u00e9e avec succ\u00e8s, cette vuln\u00e9rabilit\u00e9 permet d'\u00e9crire des donn\u00e9es en dehors de la limite du tampon en allouant une m\u00e9moire de taille manifestement inf\u00e9rieure.\n
CVE-2022-28734 \u2014 d\u00e9bordement d'un octet lors du traitement des en-t\u00eates HTTP s\u00e9par\u00e9s. Ce probl\u00e8me peut entra\u00eener la corruption des m\u00e9tadonn\u00e9es GRUB2 (enregistrement d'un octet nul imm\u00e9diatement apr\u00e8s la fin du tampon) lors de l'analyse des requ\u00eates HTTP sp\u00e9cialement con\u00e7ues.\n
CVE-2022-28735 \u2014 probl\u00e8me dans le v\u00e9rificateur shim_lock, permettant de charger des fichiers qui ne sont pas li\u00e9s au noyau. Cette vuln\u00e9rabilit\u00e9 peut \u00eatre utilis\u00e9e pour charger des modules du noyau ou du code non v\u00e9rifi\u00e9 dans le mode UEFI Secure Boot sans signature num\u00e9rique v\u00e9rifi\u00e9e.\n
CVE-2022-28736 \u2014 acc\u00e8s \u00e0 une zone de m\u00e9moire d\u00e9j\u00e0 lib\u00e9r\u00e9e dans la fonction grub_cmd_chainloader() via la r\u00e9ex\u00e9cution de la commande chainloader, utilis\u00e9e pour charger des syst\u00e8mes d'exploitation non pris en charge dans GRUB2. L'exploitation de cette vuln\u00e9rabilit\u00e9 peut entra\u00eener l'ex\u00e9cution du code de l'attaquant, si celui-ci parvient \u00e0 d\u00e9terminer les caract\u00e9ristiques de la r\u00e9partition de la m\u00e9moire dans GRUB2.\n
CVE-2022-28737 \u2014 d\u00e9bordement de tampon dans la couche shim, se produisant dans la fonction handle_image() lors du chargement et de l'ex\u00e9cution d'images EFI sp\u00e9cialement con\u00e7ues. <\/ul>\n