Firmware : le maillon des correctifs dont personne ne s’occupe, la faille UEFI le prouve

Votre EDR est excellent, votre hyperviseur à jour, vos images de conteneurs reconstruites cette nuit. Mais qui corrige le code qui s’exécute avant que tout cela n’existe ?

C’est la question dérangeante derrière CVE-2026-97631, une faille critique dans TianoCore EDK II, la base de code de référence open source utilisée par la plupart des éditeurs de firmware UEFI. D’après les résumés de l’enquête d’Ars Technica, elle se trouve dans un composant ICMP, sur le chemin de démarrage réseau, et est notée 9,5 sur 10. Elle permet à un attaquant d’exécuter du code pendant le démarrage, avant que des protections comme Secure Boot et le TPM puissent établir une chaîne de confiance.

Certains détails comptent. Les charges malveillantes ne persisteraient pas d’elles-mêmes, mais elles peuvent installer d’autre code qui s’exécute à chaque démarrage ultérieur. La faille est aussi devenue publique avant une divulgation prévue en janvier, selon un résumé d’Ars par FourWeekMBA. Et Jesse Michael, d’Eclypsium, a indiqué à Ars que la correction passe par le déploiement d’une mise à jour du BIOS/UEFI.

« La plupart des serveurs de la planète »: un titre, pas une mesure

D’abord, un peu de retenue. Le titre affirme que la faille menace la plupart des serveurs de la planète. Comme le souligne Tech Insider, les articles indiquent que le code de référence est utilisé par la plupart des constructeurs de serveurs dans le monde, mais ne donnent ni nombre de machines touchées ni pourcentage. Code partagé ne veut pas dire exposition partagée. Les builds et configurations des constructeurs diffèrent probablement, et le fait qu’une machine donnée soit accessible via ce chemin de démarrage réseau dépend vraisemblablement de sa configuration.

Selon nous, cette nuance joue dans les deux sens. Elle signifie qu’il ne faut pas redémarrer tout le parc dans la panique ce soir. Elle signifie aussi qu’on ne peut pas connaître son exposition à partir d’un titre, et nous soupçonnons que beaucoup d’organisations ne peuvent pas non plus y répondre avec leurs propres registres. C’est là le vrai sujet.

Le bug est nouveau, la chaîne défaillante est ancienne

Regardez comment voyage un correctif de firmware. Dans l’article d’Ars de 2024 sur une précédente vague de bugs UEFI, la chaîne était exposée clairement: les fabricants de firmware envoient des mises à jour à leurs clients, et ces clients mettent les correctifs à disposition de leurs propres clients, généralement les utilisateurs finaux. Chaque maillon est une entreprise distincte et, à notre avis, personne n’est responsable de l’ensemble du trajet.

Comparez avec un bug de bibliothèque. Lorsqu’une faille Brotli est apparue récemment, Google et Node.js ont livré des correctifs le 21 octobre et Microsoft a suivi avec une mise à jour d’urgence de.NET pendant le week-end, selon TechRadar. Même cela a été brouillon: les copies embarquées font que mettre à jour la seule bibliothèque de Google ne protège pas toutes les applications. Mais le correctif emprunte au moins des canaux que la plupart des équipes savent déjà exploiter, comme les mises à jour de paquets et les redéploiements. Le firmware n’offre aucune routine de ce genre. Il faut déterminer quelle image de quel fournisseur on utilise, attendre que l’OEM la reconditionne, planifier une fenêtre de maintenance et flasher des machines que l’on préfère ne pas redémarrer.

Il y a ensuite la couche où les défenseurs repéreraient normalement un problème. Le code de pré-démarrage s’exécute sous le système d’exploitation, si bien que les outils sur lesquels s’appuient la plupart des équipes y voient peut-être très peu. Le firmware a aussi connu quelques mois difficiles. En septembre, Cybernews a signalé un contournement de Secure Boot via l’UEFI Shell, reconnu par AMI, Gigabyte, Insyde et Cisco, avec probablement bien d’autres fabricants touchés. Deux incidents en deux mois ne font pas une tendance à eux seuls, mais ils désignent un point faible.

Traiter le firmware comme un produit doté d’un responsable

Notre verdict est simple: si le firmware n’a pas de responsable dans votre équipe, vous avez déjà décidé de le corriger tard. La solution relève surtout du processus, pas des outils.

• L’inventorier. Savoir quelle version de firmware et quel build de quel fournisseur se trouvent sur chaque serveur. Sans cela, répondre à « sommes-nous concernés ? » prend des jours au lieu de minutes.
• Nommer un responsable. Quelqu’un doit suivre les avis des fournisseurs et avoir l’autorité de planifier des fenêtres de maintenance, comme une équipe gère le rythme de ses correctifs d’OS.
• Réduire la surface accessible. Si vous n’avez pas besoin du démarrage réseau sur une machine, le désactiver peut être une parade peu coûteuse. Nous ne pouvons pas promettre qu’elle couvre toutes les configurations; vérifiez donc ce que dit votre fournisseur.
• Répéter le flashage. Une mise à jour du BIOS jamais testée sur votre matériel est un pari le jour où cela compte.

Les fournisseurs ont eux aussi des devoirs. Une base de code de référence partagée par toute l’industrie devrait s’accompagner d’un moyen partagé et prévisible de faire parvenir les correctifs aux clients. D’ici là, la charge pèse sur les administrateurs, ce qui n’est pas juste, mais c’est la réalité.

On ne retiendra pas cette CVE pour sa note. La question à se poser est: combien de temps votre organisation mettrait-elle à savoir lesquelles de ses machines sont exposées ? Si la réponse honnête est « il faudrait chercher », le firmware est votre trou de correctifs, et personne d’autre ne le comblera.