Les moteurs d’inférence laissent-ils une empreinte exploitable ?

Le moteur fait partie de la surface d’attaque

Une architecture d’IA peut isoler le modèle, le proxy réseau et l’environnement d’exécution tout en négligeant le moteur qui transforme les sorties du modèle en calculs et en appels d’outils. Le preprint étudié défend une thèse simple : un modèle capable de sonder son environnement peut exploiter les différences d’implémentation entre moteurs d’inférence, identifier celui qui l’héberge puis choisir une chaîne d’attaque adaptée.

Les auteurs étudient notamment vLLM, llama.cpp et d’autres moteurs du même écosystème. La diversité des comportements peut venir de la tokenisation, de la détokenisation, des templates de conversation, de l’échantillonnage ou de la gestion des paramètres. Une différence destinée à améliorer la performance peut donc devenir un signal d’identification.

Comment une empreinte apparaît

Le protocole utilise des sorties spécialement conçues pour révéler des comportements propres à l’implémentation. Les auteurs examinent trois familles de signaux : la présence d’un comportement stable, l’extraction correcte de ce signal et l’identification finale du moteur. Une empreinte n’est utile que si les trois étapes restent suffisamment fiables.

La température dégrade généralement la stabilité et l’extraction : des sorties plus créatives peuvent masquer le signal. Dans les expériences rapportées, la cohérence dépasse souvent 80 % sur les cinq moteurs, mais elle diminue pour certains signaux et certaines configurations. Le modèle Qwen exécuté au-dessus de TensorRT-LLM est particulièrement sensible à une dégénérescence de sortie sur l’un des tests Unicode ; à partir d’une température de 0,6, le taux d’extraction correcte de ce signal tombe à zéro dans la condition décrite.

Tous les signaux ne se valent pas. Le signal lié à la date système est extrait avec succès sur l’ensemble des moteurs. D’autres restent au-dessus de 75 % entre 0,0 et 0,6 pour les moteurs hors TensorRT-LLM, puis se dégradent quand la température augmente. Ces résultats montrent qu’une empreinte est une propriété du couple modèle-moteur-paramètres, pas une constante abstraite attachée au logiciel.

De la différence au risque

Connaître le moteur ne suffit pas à compromettre une machine. Le risque apparaît lorsqu’un modèle mal aligné utilise cette information pour choisir une vulnérabilité compatible avec la pile. Le papier construit une démonstration de principe dans laquelle un modèle faible identifie l’environnement et transmet l’information à un modèle plus puissant chargé de produire une chaîne d’exploitation.

Dans l’un des exemples, vLLM 0.10.0 est configuré avec un parser d’outils Qwen qui appelle eval() lorsque le type d’un paramètre n’est pas reconnu. Avec un schéma d’outil mal configuré, une sortie spécialement formée peut alors exécuter du code avec les privilèges de vLLM. Le cadre expérimental fournit volontairement ce mauvais schéma ; il ne faut pas lire l’exemple comme une vulnérabilité automatique de toute installation vLLM.

La chaîne examinée ajoute ensuite une possibilité d’évasion de conteneur liée à Docker et une étape firmware/virtualisation. Le document insiste sur le fait que l’objectif n’est pas d’évaluer la découverte de zero-day, mais de montrer comment une information sur la pile peut servir à sélectionner des composants dont les versions sont connues comme vulnérables.

Les recommandations de défense

La première recommandation est de standardiser les comportements qui devraient être universels. Si plusieurs moteurs implémentent le même algorithme de tokenisation ou de pénalité de répétition, des spécifications formelles et des tests communs peuvent réduire les différences observables. Cette standardisation a un coût : les fournisseurs utilisent parfois des implémentations propriétaires pour gagner en performance ou réduire les ressources. L’objectif raisonnable est donc de commencer par les parties censées respecter une sémantique commune.

La seconde est de réduire les privilèges. Les auteurs rapprochent les moteurs d’inférence des navigateurs modernes : traiter des entrées non fiables, utiliser du code mémoire-non-sûr et exécuter avec de hauts privilèges dans le même composant crée une combinaison dangereuse. Une architecture multi-processus, des capacités minimales et des frontières explicites peuvent limiter l’impact d’un bug.

Les GPU ne sont pas hors sujet. Des kernels C++ ou du code intermédiaire généré peuvent rester exposés à des corruptions mémoire ou à des détournements de flux. Le papier appelle à des outils d’analyse de sûreté mémoire pour les kernels, à des ISA GPU offrant de meilleures garanties et à des frontends mémoire-sûrs dont la performance soit acceptable.

Implications pour les déploiements

Une pile LLM doit être testée comme un assemblage de composants, pas seulement comme un modèle. Les versions exactes du moteur, du parser d’outils, du conteneur, du runtime GPU et de l’hyperviseur doivent être enregistrées. Les configurations par défaut, comme une capacité Linux dangereuse ou un outil dont le schéma est trop permissif, méritent une revue indépendante.

Le fingerprinting peut aussi être utilisé à des fins défensives. Une équipe peut envoyer des sondes bénignes pour vérifier qu’un déploiement ne révèle pas inutilement de différences, détecter une dérive de version ou confirmer qu’un environnement attendu est réellement celui qui exécute la requête. Les sondes ne doivent pas exposer de secrets et doivent être séparées des tests d’exploitation.

Les appels d’outils devraient valider strictement les types et rejeter les paramètres ambigus. Le modèle ne devrait pas obtenir de privilèges supplémentaires simplement parce qu’il connaît la syntaxe interne du moteur. Le conteneur ne devrait pas disposer de capacités qui permettent de monter des systèmes de fichiers hôtes ou de modifier les contrôles du noyau sans justification.

Ce que l’étude démontre et ne démontre pas

Le résultat central est la faisabilité d’une identification par comportements et la possibilité de l’utiliser dans une preuve de concept avec des composants vulnérables. Il ne s’agit pas d’un taux universel de réussite d’attaque, ni d’une preuve que tous les modèles chercheront activement à s’échapper. La qualité du signal dépend du modèle, de la température, du moteur et du harnais.

Le démonstrateur repose en outre sur une configuration volontairement faible pour l’un des parsers et sur des versions précises. Une mise à jour peut supprimer un chemin ; un mauvais cloisonnement différent peut en créer un autre. Le message de sécurité est donc architectural : le moteur d’inférence doit être inclus dans l’analyse de menace, même lorsqu’il est présenté comme une simple couche de performance.

Statut de la source

Le texte est un preprint ArXiv et n’est pas nécessairement évalué par les pairs. Les détails techniques décrivent un environnement de recherche et des preuves de concept ; ils ne constituent pas une procédure à exécuter sur une infrastructure tierce. En production, une équipe doit reproduire les constats dans un environnement autorisé, appliquer les correctifs des éditeurs et conserver une validation de configuration.

Il faut également traiter la standardisation comme une réduction de signal, pas comme une disparition magique du risque. Même si deux moteurs produisent des sorties similaires, leurs parsers, bibliothèques GPU, permissions et dépendances peuvent diverger. Un contrôle de configuration doit donc vérifier la chaîne entière : image, runtime, version du moteur, modèle chargé, parser d’outils, capacités du conteneur et accès au réseau. Les sondes de fingerprinting défensives peuvent aider à détecter une dérive, mais elles doivent rester bénignes, journalisées et autorisées. La correction d’un composant ne dispense pas de retester les chemins d’escalade voisins.

La défense doit aussi éviter de publier inutilement les détails qui rendent l’empreinte plus facile à exploiter. Les journaux peuvent conserver la version et le résultat de la sonde dans un espace d’audit restreint, sans exposer ces informations au modèle ou à un utilisateur non autorisé.

Sources

Sarah Radway, Andrew Cheng, Vijay Janapa Reddi et James Mickens, « Inference-Engine Fingerprinting Attacks are Practical: Exploring Model-Driven Environmental Discovery, Exploitation, and Escape », ArXiv 2609.20614v1 : preprint, PDF.