Linux corrige une faille qui laisse une VM prendre la main sur l’hôte

Une machine virtuelle (VM) est un ordinateur simulé par logiciel ; plusieurs tournent sur une même machine physique, l’hôte, qui doit les tenir isolées les unes des autres et de lui-même. C’est le principe des clouds et des hébergeurs : des clients qui ne se connaissent pas partagent les mêmes serveurs. PwnEscape brise cette cloison, et pas là où on l’attendait.

Une somme de contrôle écrite trop tard

Le défaut ne se trouve pas dans KVM, la brique de Linux qui fait tourner les machines virtuelles, mais dans sa pile réseau, le code qui traite les paquets de données. Chaque paquet porte une somme de contrôle, un petit nombre calculé sur son contenu qui permet de détecter une erreur de transmission. Pour gagner du temps, Linux sait remettre ce calcul à plus tard : l’expéditeur indique seulement à partir de quel octet compter et où écrire le résultat.

Or une machine virtuelle peut fournir elle-même ces indications. Selon le scénario détaillé dans la fiche CVE, une VM malveillante envoie un paquet par virtio-net, sa carte réseau virtuelle ; le logiciel qui fait tourner la VM le transmet à l’interface TAP de l’hôte (une carte réseau simulée côté serveur), et le paquet entre dans la pile IPv4 de l’hôte. Celui-ci vérifie l’en-tête du paquet, le juge valide, puis, au moment de le découper en morceaux, effectue le calcul différé de la somme de contrôle à l’endroit indiqué par la VM : en plein dans l’en-tête qu’il vient de valider.

Le billet de pwn.ai montre l’effet : la valeur écrite change la longueur d’en-tête annoncée, qui passe de 20 à 60 octets. L’hôte croit alors le paquet plus long qu’il n’est et recopie dans les morceaux envoyés 32 octets de sa propre mémoire. En répétant l’opération, le chercheur a obtenu une fuite continue, puis des écritures choisies de 64 octets dans la mémoire du noyau hôte, et enfin, sur ses propres machines de test, l’exécution d’un programme avec les droits d’administrateur. La fiche CVE précise qu’aucune course ni fenêtre de temps n’est nécessaire, et que des paquets piégés ont fait planter la machine physique, « faisant tomber tous les bacs à sable qu’elle héberge ».

Le correctif, écrit par Michael S. Tsirkin, ingénieur de Red Hat, ajoute une vérification simple : le calcul est refusé s’il doit s’écrire avant la fin de l’en-tête IPv4. Son message de commit reste prudent : de tels paquets pouvaient « faire tout un tas de dégâts », « nous ne devrions vraiment pas laisser entrer de tels paquets », et cette vérification n’est qu’une mesure de défense en profondeur, en attendant « une validation plus complète à l’entrée ». Il note aussi que le problème a été « reproduit indépendamment par d’autres depuis » son signalement.

Le commit vise deux modifications d’origine : celle de 2008 qui a permis à l’interface TAP d’accepter ces indications de somme de contrôle, et une autre qui a fait de même pour les « prises de paquets » (une façon pour un programme d’envoyer des paquets bruts). C’est sans doute pourquoi la fiche de Red Hat parle d’« un attaquant local ou une machine virtuelle invitée non fiable » ; aucune des sources ne décrit d’attaque par ce second chemin.

9,3 ou 8,8 sur 10 : deux façons de compter les droits de l’attaquant

Les notes divergent. La CNA Linux, l’équipe du noyau habilitée à attribuer les numéros CVE, donne 9,3 sur 10, « critique ». Red Hat, qui retenait 7,0 le 16 octobre, affichait 8,8 le 17 octobre ; Ubuntu classe la faille en priorité « moyenne ». Entre la CNA et Red Hat, l’écart ne tient plus qu’à une question : faut-il des droits pour attaquer ?

Pour la CNA, il ne faut aucun droit sur l’hôte : un client qui peut émettre depuis sa propre carte réseau virtuelle suffit. Red Hat compte au contraire les droits nécessaires dans la machine invitée, comme AWS, qui parle de « quelqu’un disposant d’un accès privilégié dans une machine virtuelle invitée ». Les deux lectures se rejoignent dans le cas qui compte : chez un hébergeur, le client est administrateur de sa propre VM. La documentation de Vercel Sandbox, par exemple, promet un accès administrateur (root) complet. Pour un hébergeur qui accueille du code d’inconnus, la nuance n’a pas de portée pratique : ses clients disposent de ces droits, et la faille le concerne pleinement, quelle que soit la note retenue.

En revanche, toutes les sources s’accordent sur un point : la faille ne s’exploite pas depuis Internet. Le chemin d’attaque est, selon la fiche CVE, « une voie locale par périphérique virtuel, pas une voie de réception depuis Internet ».

Amazon hors de cause, Debian corrige sa version stable

Le bulletin d’AWS, publié le 15 octobre, met hors de cause ses services gérés (EC2, Lambda, Fargate) et vise les clients qui font tourner eux-mêmes des machines virtuelles sous KVM avec virtio-net, « y compris Firecracker », un logiciel qui fait tourner des microVM, des machines virtuelles très légères. Il liste les noyaux corrigés d’Amazon Linux. Il situe les versions touchées « de 4.4 à 6.18 », quand la fiche officielle remonte à 2.6.27 : c’est la fiche du noyau qu’il faut retenir pour un autre système qu’Amazon Linux.

Noyaux Amazon Linux corrigés (bulletin AWS du 15 octobre)

• Amazon Linux 2 : kernel-4.14.355-287.750.amzn2, kernel-5.4.302-229.494.amzn2, kernel-5.10.269-270.1108.amzn2, kernel-5.15.220-156.256.amzn2
• Amazon Linux 2023 : kernel-6.1.188-233.385.amzn2023, kernel6.12-6.12.110-135.201.amzn2023, kernel6.18-6.18.51-120.162.amzn2023

Debian a corrigé sa version stable, Debian 13 « trixie », le 16 octobre (avis DSA-6568-1, noyau 6.12.113-1). Son suivi de sécurité marquait encore, le 17 octobre, la version précédente « bookworm » et la future « forky » comme vulnérables ; la branche de développement « sid » est corrigée avec le noyau 7.2.11. Chez Ubuntu, le correctif n’avait pas encore atteint les versions publiées le 17 octobre : sa fiche indiquait toujours « à évaluer » pour toutes, de 14.04 à 26.04. Le même jour, la fiche de Red Hat ne donnait toujours pas d’état par produit lisible. L’équipe du noyau, dans son annonce, recommande comme toujours de passer à la dernière version stable plutôt que de reprendre ce seul correctif.

Trouvée en trois jours, avec une IA, pour un concours

PwnEscape est née d’un concours. Le 18 août, Vercel, qui vend des bacs à sable pour exécuter le code produit par des agents d’IA, a promis jusqu’à un million de dollars à qui percerait l’isolement de son service, où chaque bac à sable tourne dans sa propre microVM Firecracker. Selon son bilan du 14 octobre, le défi a reçu 1 285 rapports en deux semaines et versé 242 000 dollars ; un seul rapport a été classé critique, celui de Paulos Yibelo, chercheur de la société pwn.ai, déposé le troisième jour. Vercel ne dit pas combien il a touché.

La fuite de mémoire a été démontrée sur les bacs à sable de production de Vercel ; le plantage et l’exécution de code, sur des machines KVM et Firecracker du chercheur configurées comme celles de Vercel. L’entreprise dit avoir travaillé avec AWS « et d’autres partenaires du secteur » pour accélérer le correctif, et affirme qu’« aucun rapport n’a montré que quiconque ait accédé aux données des clients dans Vercel Sandbox ». Elle ne dit pas à quelle date ses propres serveurs ont été corrigés.

Le chercheur décrit un travail en tandem : « les humains ont mené la recherche », formulé les questions et dirigé les investigations, tandis que GPT-5.6 Sol, le modèle d’IA utilisé, a servi de « moteur de raisonnement principal » pour lire le code source et explorer les pistes d’attaque. Vercel explique d’ailleurs le volume de rapports reçus par le fait que les chercheurs « chassent désormais à la vitesse de l’IA ». Le même mouvement pousse OpenSSH à accélérer ses versions et a conduit Google à suspendre une partie de ses primes devant l’afflux de rapports automatisés ; ici, le rapport était juste, et grave.

La chronologie publiée par pwn.ai et reprise sur la liste oss-security donne la mesure des délais : premier signalement à Vercel le 20 août, alerte aux responsables de la sécurité du noyau le 4 septembre, reproduction confirmée le 7, correctif accepté le 8 octobre et intégré à la branche principale de Linux le 14, versions stables le 15.

Une deuxième partie annoncée

Plusieurs points restent ouverts. Le chercheur n’a pas publié de code d’attaque ; il annonce une deuxième partie, sans date, consacrée au passage de la fuite de mémoire à la prise de contrôle de l’hôte, qu’AWS ne mentionne pas dans son bulletin (il parle de fuite et de déni de service). Il prévient toutefois que des attaques devraient apparaître « d’ici quelques semaines » sur les configurations les plus faibles, et en moins d’un mois sur les configurations par défaut des logiciels de virtualisation. Les autres hébergeurs et clouds, les autres logiciels de virtualisation et les conteneurs n’apparaissent dans aucune des sources consultées : leur exposition dépend de la façon dont leurs machines virtuelles sont reliées au réseau de l’hôte, et seul leur éditeur peut la confirmer. Enfin, le développeur du correctif le dit lui-même : la vraie réparation, qui filtrera ces paquets dès leur entrée dans le noyau, « demande encore du travail ». Pour la cloison entre machines virtuelles, la leçon vaut au-delà de ce cas : elle ne tient pas qu’au logiciel de virtualisation, mais à tout le code de l’hôte que touchent les données d’un client.

Les citations de sources en anglais (fiche CVE, commit, AWS, Vercel, pwn.ai) ont été traduites par la rédaction.