Vercel Sandbox résiste à l'assaut : 1285 rapports, $242 000 versés et une faille dans le noyau Linux

Vercel a clos son défi de hacking autour de Vercel Sandbox, un environnement cloud pour l'exécution isolée de code. En deux semaines, les chercheurs ont envoyé 1285 rapports et Vercel a versé $242 000 de récompenses. Aucun rapport ne démontre d'accès aux données des clients. Pourtant, la trouvaille la plus grave ne concerne pas le code de Vercel, mais le socle sur lequel repose une bonne partie des clouds : une vulnérabilité zero-day a été découverte dans la pile réseau du noyau Linux.

Un zero-day dès le troisième jour

Le rapport principal est arrivé le troisième jour du programme. Paulos Yibelo (pwn.ai), chercheur sur HackerOne, travaillait depuis une sandbox ordinaire, sans privilèges particuliers. Il a trouvé un défaut dans la pile réseau du noyau Linux : des paquets spécialement forgés, envoyés depuis l'intérieur d'une micro-VM, permettaient de mener trois attaques distinctes.

• Fuite de la mémoire de l'hôte par le réseau. La mémoire de la machine, que la sandbox partage avec d'autres locataires, se retrouvait dans les paquets que l'invité envoyait vers Internet. La fuite était continue tant que l'invité continuait d'émettre du trafic. L'attaque a été démontrée sur des sandboxes Vercel en production.
• Plantage de l'hôte. Deux paquets suffisaient à faire tomber la machine, et avec elle toutes les sandboxes qui y tournaient.
• Exécution de code sur l'hôte. Le même défaut permettait de lancer des commandes avec les pleins droits d'administrateur et de sortir de la frontière d'isolation.

Le chercheur a reproduit le plantage et l'exécution de code sur ses propres machines équipées de KVM et de Firecracker, qui répliquent la configuration de Vercel Sandbox.

Presque tous les grands fournisseurs cloud isolent leurs clients précisément à ce niveau du noyau : le risque concerne donc l'infrastructure partagée. Vercel indique avoir travaillé avec le chercheur, ainsi qu'avec AWS et d'autres partenaires, pour accélérer la correction. En parallèle, Yibelo a contacté les mainteneurs du noyau et préparé avec eux des correctifs candidats. Ceux-ci passent une vérification à huis clos, aucun CVE n'a encore été attribué et les détails ne sont pas divulgués. L'entreprise a communiqué sur l'existence de la faille parce qu'elle faisait déjà l'objet de discussions publiques.

Le regard de l'intérieur : un stagiaire et Trail of Bits

En plus de la chasse publique aux bugs, Vercel a mené des audits internes avec un accès complet au code source et fait appel à Trail of Bits. Toutes les trouvailles ne sont pas venues de l'extérieur. Un stagiaire de Vercel, Marcos Hernanz, a découvert une fuite entre locataires dans la couche de stockage Linux device-mapper : n'importe quelle sandbox pouvait lire les blocs disque réutilisés de sandboxes supprimées auparavant.

Trail of Bits a consacré quatre semaines-ingénieur à l'audit, avec deux spécialistes mobilisés. Ils disposaient d'un accès complet aux dépôts et de deux environnements de test d'entreprise. Résultat : 20 constats, chacun testé, confirmé et rattaché à un endroit précis du code. La revue d'architecture a montré que la frontière de virtualisation est fiable. Chaque sandbox tourne dans une micro-VM Firecracker distincte avec son propre noyau invité, le modèle de périphériques est volontairement minimal, et aucun invité ne partage son noyau en cours d'exécution ni avec l'hôte ni avec un autre locataire.

Trois enseignements structurels

Les auditeurs ont formulé trois recommandations, et Vercel affirme les avoir toutes appliquées.

• Supprimer la confiance envers l'invité. La couche de gestion acceptait les valeurs renvoyées par les logiciels à l'intérieur de la micro-VM, alors que toute valeur de ce type est, en pratique, saisie par le locataire. Tout ce qui franchit la frontière est désormais calculé côté serveur ou signé avec une clé inaccessible à l'invité.
• Une politique, un arbitre. Le contrôle du trafic sortant était éparpillé entre plusieurs sous-systèmes, chacun analysant seul la politique réseau, et leurs décisions ne coïncidaient pas toujours. Désormais, il y a une seule procédure de canonicalisation par type de données et un seul composant par décision, et les connexions sont revérifiées à chaque changement de politique.
• Partir du principe que le prochain zero-day arrivera. La protection autour de chaque sandbox a été renforcée pour limiter les dégâts en cas de compromission du logiciel de virtualisation. Les noyaux des hôtes sont mis à jour, la virtualisation imbriquée est désactivée, et le jailer de Firecracker lance chaque processus de micro-VM avec des droits réduits.

Ce que cela change pour ceux qui exécutent du code tiers

Les sandboxes pour agents IA et code généré deviennent un élément standard de la pile, et ce cas montre où se situe réellement le risque. La micro-VM dotée d'un noyau distinct a tenu : même avec une vulnérabilité dans l'hôte, personne n'a pu extraire de données clients. Mais l'isolation ne dispense ni de mettre à jour les noyaux des hôtes ni de se méfier de tout ce qui revient de l'invité.

Les équipes qui construisent leurs propres sandboxes ou choisissent un fournisseur devraient vérifier trois points : la couche de gestion accepte-t-elle des données de l'invité sans les contrôler, l'analyse des politiques réseau est-elle dupliquée dans plusieurs composants, et à quelle vitesse le fournisseur déploie-t-il les correctifs du noyau. Les détails sur les CVE seront publiés après la sortie des correctifs ; il faudra alors comparer ses propres versions de noyau et configurations Firecracker.