Une vuln\u00e9rabilit\u00e9 (CVE-2023-40547) a \u00e9t\u00e9 identifi\u00e9e dans la couche Shim, utilis\u00e9e dans la plupart des distributions Linux pour le d\u00e9marrage s\u00e9curis\u00e9 en mode UEFI Secure Boot, pouvant entra\u00eener une ex\u00e9cution de code \u00e0 distance et un contournement du m\u00e9canisme de d\u00e9marrage s\u00e9curis\u00e9 UEFI. Un attaquant contr\u00f4lant le serveur HTTP auquel Shim fait appel peut renvoyer une r\u00e9ponse sp\u00e9cialement con\u00e7ue, entra\u00eenant une \u00e9criture contr\u00f4l\u00e9e en dehors de la zone tampon pour ex\u00e9cuter du code \u00e0 un stade pr\u00e9coce du d\u00e9marrage. <\/p>\n
La vuln\u00e9rabilit\u00e9 est caus\u00e9e par une erreur dans le code de chargement de fichiers via HTTP, qui se manifeste lors du traitement des r\u00e9ponses incorrectes renvoy\u00e9es par le serveur HTTP auquel le shim acc\u00e8de. Le mode HTTPBoot dans Shim est pris en charge depuis 2016 et permet d'organiser le d\u00e9marrage \u00e0 partir du r\u00e9seau en utilisant le protocole HTTP pour extraire le fichier avec le chargeur appel\u00e9 \u00e0 l'\u00e9tape suivante. Lors du chargement de fichiers via HTTP, Shim r\u00e9serve un tampon pour les donn\u00e9es entrantes, en tenant compte non pas de la taille r\u00e9elle des donn\u00e9es, mais de la taille indiqu\u00e9e dans l'en-t\u00eate HTTP \u00ab Content-Length \u00bb. Par cons\u00e9quent, en renvoyant une valeur inf\u00e9rieure dans l'en-t\u00eate Content-Length, il est possible de faire enregistrer la queue de la requ\u00eate dans la m\u00e9moire en dehors du tampon. <\/p>\n
Shim est sign\u00e9 num\u00e9riquement par Microsoft et v\u00e9rifie GRUB2 avec son propre certificat, permettant aux d\u00e9veloppeurs de distributions de ne pas signer chaque mise \u00e0 jour du noyau et de GRUB aupr\u00e8s de Microsoft. La vuln\u00e9rabilit\u00e9 dans Shim permet de s\u2019immiscer dans la cha\u00eene de confiance en mode Secure Boot actif et d'obtenir un contr\u00f4le total sur le processus de d\u00e9marrage ult\u00e9rieur, par exemple pour d\u00e9marrer un autre syst\u00e8me d'exploitation, modifier des composants du syst\u00e8me d'exploitation et contourner la protection Lockdown. <\/p>\n
La vuln\u00e9rabilit\u00e9 a \u00e9t\u00e9 corrig\u00e9e dans la version 15.8 de Shim, mais pour bloquer compl\u00e8tement l'attaque via Shim, une validation de la nouvelle version par Microsoft est n\u00e9cessaire, ainsi que son int\u00e9gration dans les distributions. Le statut de la correction de la vuln\u00e9rabilit\u00e9 dans les distributions peut \u00eatre \u00e9valu\u00e9 sur les pages suivantes : Debian, Ubuntu, SUSE, RHEL, Fedora. Le probl\u00e8me est qu'en l'absence de r\u00e9vocation de la signature pour l'ancienne version, le correctif est inutile, car l'attaquant peut utiliser un support de d\u00e9marrage avec une version vuln\u00e9rable de Shim pour compromettre UEFI Secure Boot. Cependant, la r\u00e9vocation de la signature entra\u00eenerait l'impossibilit\u00e9 de d\u00e9marrages valid\u00e9s pour les distributions continuant \u00e0 utiliser l'ancienne version de Shim. <\/p>\n
Pour bloquer la vuln\u00e9rabilit\u00e9 sans r\u00e9voquer la signature num\u00e9rique, les distributions peuvent utiliser le m\u00e9canisme SBAT (UEFI Secure Boot Advanced Targeting), dont le support est mis en \u0153uvre pour GRUB2, shim et fwupd dans la plupart des distributions Linux populaires. 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 des listes de composants autoris\u00e9s ou interdits pour le d\u00e9marrage s\u00e9curis\u00e9 UEFI. <\/p>\n
SBAT permet de bloquer l'utilisation de la signature num\u00e9rique pour des num\u00e9ros de version sp\u00e9cifiques des composants sans avoir besoin de r\u00e9voquer les cl\u00e9s pour Secure Boot. Le blocage des vuln\u00e9rabilit\u00e9s via SBAT ne n\u00e9cessite pas l'utilisation de la liste des certificats UEFI r\u00e9voqu\u00e9s (dbx), mais se fait au niveau du remplacement de la cl\u00e9 interne pour g\u00e9n\u00e9rer des signatures et mettre \u00e0 jour GRUB2, shim et d'autres artefacts de d\u00e9marrage fournis par les distributions. <\/p>\n
En plus de la vuln\u00e9rabilit\u00e9 examin\u00e9e dans Shim 15.8, plusieurs probl\u00e8mes moins critiques exploit\u00e9s localement ont \u00e9galement \u00e9t\u00e9 corrig\u00e9s : <\/p>\n