Branle-bas de combat chez les principaux fournisseurs de firmwares UEFI. Une faille critique dans EDK II permet à un attaquant d'exécuter du code malveillant avant même le chargement du système d'exploitation. Le nombre de serveurs concernés demeure inconnu, mais la diffusion de ce code pourrait imposer des vérifications et des mises à jour à très grande échelle.
Cette fois, mettre à jour l’OS ne suffira pas à régler le problème : la vulnérabilité touche le firmware UEFI chargé d'initialiser le matériel et de préparer le démarrage avant que le système d'exploitation prenne la main. Pour le concevoir, des fournisseurs comme AMI, Insyde et Phoenix s'appuient sur EDK II, une base de code open source reprise dans les firmwares de serveurs du monde entier. Des chercheurs d'Anthropic et de Google y ont décelé une erreur de gestion de la mémoire vieille de 16 ans, que TianoCore, la communauté responsable du projet, a rendue publique la semaine dernière. Le correctif a déjà été intégré au code source d'EDK II, mais sa distribution s'annonce autrement plus compliquée que sa mise au point.
Protégez votre entreprise gratuitement pendant 30 jours
Découvrez Bitdefender Ultimate Small Business Security et protégez votre activité contre les cybermenaces. Aucune coordonnée bancaire requise.
Une erreur de mémoire exploitable avant le chargement du système
Pour comprendre de quoi il retourne, il faut savoir que dans les centres de données, le démarrage réseau, ou PXE, permet aux administrateurs d'installer ou de restaurer des serveurs sans intervenir physiquement sur chacun d'eux. Lorsqu'une machine démarre de cette façon, elle récupère sur le réseau un programme qui lui permet ensuite de lancer un système d'exploitation, un outil d'installation ou un environnement de maintenance. Elle peut ainsi être préparée à distance, même si son disque ne contient encore aucun système fonctionnel.
Pendant cette opération, le firmware reçoit également des messages ICMP, utilisés entre autres pour signaler des erreurs de communication sur le réseau. EDK II leur réserve un espace mémoire de 504 octets, mais le programme ne vérifie pas correctement la quantité de données qu'il y copie. Lorsqu'un message dépasse la taille prévue, les données supplémentaires débordent de cet espace et écrasent une partie de la mémoire voisine. Ce dépassement de tampon, désormais référencé CVE-2026-97631, affiche un score de gravité de 9,5/10 selon TianoCore.
Si cette faille est considérée comme critique, c'est parce qu'un attaquant capable d'envoyer un message ICMP piégé pendant cette phase de démarrage peut provoquer le plantage du serveur et empêcher le lancement du système. Plus grave encore, s'il connaît suffisamment bien la version du firmware ciblé, il peut également détourner l'exécution du programme pour lancer son propre code au niveau de privilège le plus élevé du processeur. Et comme l'attaque se joue avant que Secure Boot ait pu vérifier les composants du système d'exploitation, elle pourrait permettre l'installation d'une charge malveillante persistante.
Un correctif publié trop tôt, mais qui pourrait arriver très tard
Selon Ars Technica, les chercheurs Alex Matrosov, d'Anthropic, et Dan Holmes-Mitra, de Google, avaient initialement prévu de révéler la vulnérabilité en janvier 2027, afin de laisser aux fabricants le temps de préparer leurs patchs. Mais dès septembre, AMI a bousculé ce calendrier en publiant sur GitHub une proposition de correction qui permettait aussi de repérer les lignes de code à l'origine de la faille. TianoCore a finalement intégré le correctif à EDK II le 15 octobre, avant de publier son avis de sécurité une semaine plus tard.
Le patch ne nécessite pas de modifier les clés ou les certificats Secure Boot, contrairement à certaines vulnérabilités découvertes par le passé. Son déploiement doit néanmoins passer par plusieurs intermédiaires : les fournisseurs de firmwares doivent d'abord intégrer le code corrigé, puis les fabricants de serveurs publier de nouvelles versions UEFI pour leurs équipements. Les entreprises devront ensuite installer ces mises à jour sur leurs machines.
Cette chaîne de mises à jour s'annonce d'autant plus laborieuse que l'étendue exacte des équipements affectés demeure inconnue. Intel assure n'avoir identifié aucun produit vulnérable parmi ceux qu'il prend encore en charge, tout en précisant que des fabricants de cartes mères peuvent avoir intégré le composant à leurs propres firmwares. Arm estime de son côté que la faille ne touche pas directement ses produits. AMD, AMI, Phoenix, Microsoft et Amazon n'avaient pas répondu aux sollicitations d'Ars Technica lors de la publication de son enquête.
Du côté des hébergeurs, Hetzner a annoncé le 28 octobre avoir ouvert une enquête pour déterminer si ses équipements sont concernés, tout en recommandant à ses clients d'éviter les redémarrages des machines utilisant PXE jusqu'à nouvel ordre.
En attendant, les administrateurs doivent vérifier auprès des fabricants si leurs serveurs embarquent le composant vulnérable et désactiver le démarrage réseau lorsqu'il n'est pas nécessaire. Les serveurs qui ne reçoivent plus de mises à jour de leur fabricant pourraient ne jamais bénéficier du correctif.
