Une faille dans l’UEFI menace les serveurs utilisant le démarrage réseau Vitesse et précipitation Illustration : Flock Vincent Hermann Le 28 octobre à 11h29 Une faille de sécurité critique a été découverte dans la plupart des firmwares UEFI utilisés dans les serveurs. Bien qu’elle ne requière pas d’authentification, il faut remplir plusieurs conditions pour l’exploiter, dont l’utilisation du PXE pour le démarrage réseau. Une erreur ?

Quand on allume un ordinateur, un petit logiciel est d’abord chargé d’initialiser le matériel et de préparer les conditions au lancement du système d’exploitation. On l’a historiquement appelé « BIOS » (Basic Input/Output System), mais il s’agit depuis longtemps d’un microgiciel (firmware) nommé UEFI (Unified Extensible Firmware Interface). Parmi les fonctions apportées par ce firmware plus moderne, des fonctionnalités réseau en standard.

Dans la grande majorité des cas, les constructeurs n’écrivent pas leur UEFI depuis zéro. Ils se basent sur des travaux existants, en particulier EDK II, une base de code libre maintenue par le projet TianoCore. Presque tous les éditeurs de firmware – dont AMI, Insyde et Phoenix – s’en servent copieusement, y compris Project Mu, une variante renforcée (durcie) d’EDK II maintenue par Microsoft.

Or, c’est dans cette base EDK II que réside la faille. Un débordement en mémoire La faille en question, estampillée CVE-2026-97631, réside dans la fonction de démarrage réseau, ou PXE. Quand elle est activée, la machine ne démarre pas sur son disque, elle récupère son système sur un serveur distant.

Ce mécanisme est largement utilisé dans les centres de données pour installer ou réinstaller en masse des serveurs. Pendant ce démarrage réseau, le pilote PXE (NetworkPkg ou UefiPxeBcDxe) attend d’éventuels messages d’erreur ICMP. S’il en reçoit, il les copie dans une zone de mémoire de taille fixe, précisément 504 octets.

Il existe deux variantes du code pour le réseau, une pour IPv4, l’autre pour IPv6. C’est là que réside le problème : dans les deux cas, la copie en mémoire continue même si le message d’erreur dépasse les 504 octets. En outre, le pointeur de destination avance sur la base du total cumulé au lieu de la taille du seul fragment copié.

Dans le scénario d’une attaque, un pirate peut donc exploiter ce mécanisme pour écrire un message trop long, avec des octets choisis en dépassement de la zone prévue en mémoire. Rien en amont ne limite la taille du message, renforçant l’ampleur du problème. Le pirate peut donc glisser des instructions dans ces octets, qui seront alors exécutées par le firmware UEFI.

Les conditions d’exploitation La faille CVE-2026-97631 affiche un score CVSS 4.0 de 9,5 sur 10, soit très près du maximum. Le seul facteur limitant la portée de l’exploitation est l’obligation d’utiliser PXE, ce qui n’arrive que dans des environnements spécifiques, et a priori pas chez le grand public. Autre condition tout de même, il faut connaitre la version exacte du firmware que l’on veut attaquer.

Si ces deux conditions sont remplies, tout ce que le pirate a à faire est d’envoyer un message d’erreur ICMP spécialement conçu pour y glisser des commandes. Aucune authentification n’est nécessaire. De plus, puisque les commandes sont exécutées à un stade très précoce de la chaine de démarrage, ni Secure Boot ni le démarrage mesuré n’ont le temps d’intervenir.

C’est l’accumulation de ces deux éléments – aucune authentification et déclenchement avant tous les mécanismes de sécurité – qui donne son score de gravité à la faille. S’il parvient à exploiter la faille, le pirate a même le choix : se servir de la corruption mémoire pour provoquer une exception processeur et le blocage du démarrage, ou l’exécution du code qui aura alors le niveau de privilège le plus élevé. Même si ce code ne survit pas lui-même au redémarrage, il peut être utilisé pour installer des composants persistants.

Une divulgation « ratée » La faille a été découverte par Alex Matrosov d’Anthropic et Dan Holmes-Mitra de Google, qui ont également fourni la solution recommandée. On ne sait pas quand cette découverte a eu lieu, mais la communication de l’équipe de TianoCore a entrainé une réservation de l’identifiant CVE le 24 septembre. En théorie, les détails d’une telle vulnérabilité restent secrets jusqu’à ce que ces correctifs soient disponibles, mais il y a eu une erreur.

Ars Technica parle de « divulgation ratée » : AMI a publié fin septembre une demande de modification publique qui décrivait la faille et contenait le correctif. Alex Matrosov et Dan Holmes-Mitra s’en sont aperçus, ont prévenu TianoCore, qui a alors décidé de rendre public l’avis de sécurité le 22 octobre. En outre, bien que le correctif ait effectivement été proposé, les différentes parties s’étaient mises d’accord pour attendre une publication des détails en janvier.

L’erreur d’AMI a précipité le calendrier, car le délai devait servir aux éditeurs de firmwares à proposer de nouvelles moutures. Il faut désormais surveiller ce que des entreprises comme Dell, Lenovo, SuperMicro ou encore HPE publient. Selon les cas, le mécanisme de mise à jour peut être plus ou moins complexe, mais il réclame dans tous les cas un temps d’immobilisation du serveur.

Les firmwares concernés sont a priori très nombreux, sur la base du code vulnérable d’EDK II. Ars Technica a interrogé Intel et Arm sur la portée du problème, les deux entreprises affirmant que leurs produits ne sont pas concernés. Nos confrères indiquent cependant que l’une comme l’autre utilisent amplement EDK II comme base de référence.

Dans le cas d’Intel, le dépôt GitHub pour les binaires FSP (Firmware Support Package) mentionne clairement EDK II et TianoCore. Même chose pour Arm. D’autres entreprises comme AMD, Microsoft et Amazon n’ont pas répondu aux questions de nos confrères, mais elles sont très probablement concernées aussi.

La méfiance est donc de mise. Il est recommandé de dresser l’inventaire des machines utilisant PXE. Si parmi elles certaines l’ont activé sans l’utiliser, mieux vaut le désactiver pour supprimer la surface d’attaque.

Si la fonction est nécessaire, il est recommandé de garder le trafic de démarrage sur un segment isolé du réseau, de surveiller les pages de support des constructeurs ou des éditeurs impliqués et de filtrer les messages ICMP inattendus. Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.

Accédez en illimité aux articles d'un média expert Profitez d'au moins 1 To de stockage pour vos sauvegardes Intégrez la communauté et prenez part aux débats Partagez des articles premium à vos contacts Abonnez-vous darkjack Premium Il y a 28 minutes Voir les réponses Message 1 Aller au commentaire enfant Signaler Bloquer cet utilisateur Il me semble qu'il faudrait que l’attaquant soit en interne, qu'il n'y ait pas de vlan isolant le réseau utilisateur du réseau de l'infrastructure. Et hors des réseaux de l'entreprise ou administration, il faudrait que le firewall laisse passer une requête de boot PXE.Je ne suis pas spécialiste en sécurité réseau mais cela me semble un peu alarmiste? Qu'en penses les druides de la sécurité réseau ici présents? alex.d.

Premium À l'instant En réponse à Message 1.1 Signaler Bloquer cet utilisateur Oui, ça me semble très alarmiste, alors qu'il faut que l'attaquant ait accès au réseau d'admin des serveurs. Si tu as accès à ce réseau, l'attaque la plus simple n'est sans doute pas de forger un paquet ICMP qui va faire un dépassement de buffer dans l'UEFI, ce serait plutôt de monter un serveur PXE pirate qui balance une image vérolée (pas d'authentification dans PXE) en répondant plus vite que le serveur officiel. ben51 Premium Il y a 18 minutes Message 2 Signaler Bloquer cet utilisateur Aller linuxboot et c'est bon Polaris Premium Il y a 16 minutes Message 3 Signaler Bloquer cet utilisateur Magnifique illustration Flock 🤩 potn Premium Modifié il y a 12 minutes Message 4 Historique Signaler Bloquer cet utilisateur Je me trompe où il faut aussi que la faille soit exploitée pile au moment du reboot du serveur ?Car si c'est bien le cas, il "suffit" de ne pas reboot le serveur, n'est-ce pas ?Le danger semble grand, mais le risque très faible. Signaler un commentaire Voulez-vous vraiment signaler ce commentaire ?

Non Oui