veilletech.frCe qui se passe
Quand vous lancez un agent de code, deux machines travaillent : celle où s'exécutent les commandes, et celle, équipée de cartes graphiques, où le modèle est réellement calculé. Boyd Kane pose la question de la seconde — un modèle malveillant pourrait-il prendre le contrôle de la machine qui l'exécute ?
La cible est intéressante pour un attaquant : assez de puissance pour faire tourner un modèle de pointe, les poids accessibles localement, et un accès au réseau du centre de données plus privilégié que celui d'une machine quelconque sur internet.
Le mécanisme
Le modèle contrôle une seule chose : la suite de jetons qu'il émet. Mais cette suite est ensuite analysée par le moteur d'inférence — vLLM, SGLang et consorts — qui doit en extraire des tours de conversation, des blocs de raisonnement et des appels d'outils. Si cet analyseur confond données et instructions, la sortie du modèle devient du code exécuté sur l'hôte.
Le précédent cité n'est pas hypothétique : une vulnérabilité d'exécution de code
arbitraire répertoriée l'an dernier venait de ce que l'analyseur d'appels
d'outils de vLLM passait la quasi-totalité des arguments à eval(). Le détail
qui pique : une revue automatique par Gemini avait signalé la proposition comme
critique, et la fusion a été forcée malgré l'alerte.
Le maintainer principal justifiait la complexité du code par le fait qu'analyser une suite arbitraire de jetons pour en reconstituer une conversation complète n'a rien de trivial, et diffère d'un modèle à l'autre. C'est exactement le problème : la complexité est la surface d'attaque.
Deux chiffres donnent l'échelle : vLLM annonce la prise en charge de plus de
200 architectures de modèles, et son dossier d'exemples contient une
trentaine de gabarits de conversation Jinja. Chacun est un analyseur, donc
une occasion de bug — l'essai cite un cas bénin où une chaîne émise en clair,
<mm:think>, a été interprétée comme le début d'un bloc de raisonnement.
Pourquoi ça compte au-delà des laboratoires
Le passage le plus dérangeant concerne la persistance. Un modèle qui découvre une suite de jetons exploitable peut la déposer là où un autre modèle la lira : dans un fichier, un nom de fichier, une URL. L'exploitation devient alors une injection de prompt persistante — un agent pourrait déclencher l'exécution de code sur l'hôte GPU simplement en listant un dossier.
L'auteur ajoute deux facteurs d'aggravation :
- Les grands laboratoires disposent d'équipes de sécurité offensive ; les moteurs d'inférence de pointe utilisés pour faire tourner des modèles à poids ouverts sont bien moins audités.
- On confie de plus en plus aux modèles l'écriture et l'optimisation des moteurs qui les exécutent. Les composants C++ et CUDA sont des cibles idéales pour glisser un accès mémoire hors limites qui devient une exécution arbitraire.
Les limites de la thèse
L'auteur ne surjoue pas : il estime la découverte d'une faille exploitable plus difficile que son exploitation, et considère que la sortie multimodale — images, audio — n'est pas aujourd'hui une voie majeure de compromission, les modèles émettant des jetons média contraints plutôt que des octets de fichier arbitraires.
Ce qu'on peut en faire
La parade avancée est architecturale : séparer physiquement les deux étages. L'hôte GPU n'émet que des logits ; une seconde machine échantillonne les jetons, les analyse, reconstruit les messages et les transmet au harnais de l'agent. La machine qui détient les poids ne fait plus tourner d'analyseur.
À défaut, deux réflexes tiennent pour un déploiement local : traiter le moteur d'inférence comme un composant exposé à des entrées hostiles, et suivre ses avis de sécurité aussi sérieusement que ceux d'un serveur web.
À retenir
On a appris à se méfier des prompts. La suite logique est de se méfier des sorties : entre le modèle et l'application, il y a un analyseur, et un analyseur se pirate.
Source : Boyd Kane