if ( !emtpy($headline_subheadline ) ) : ?>
RunSybil a démontré l’exécution de code via un modèle de modèle malveillant. Python affirme que les évasions du bac à sable ne relèvent pas de son modèle de menace de sécurité.
endif; ?>
Une faille de sécurité de la mémoire dans CPython peut permettre à des modèles de modèles d’IA malveillants d’échapper aux bacs à sable de code et d’exécuter du code arbitraire à l’intérieur des serveurs d’inférence, selon les chercheurs en sécurité de RunSybil.
« En exploitant cette vulnérabilité, les attaquants pourraient prendre pied à l’intérieur des serveurs responsables du traitement de millions de requêtes d’utilisateurs », a écrit Darius Houle, chercheur en sécurité chez RunSybil, dans un article de blog. « Ils pourraient également s’attaquer directement à l’infrastructure cloud sous-jacente qui héberge ces charges de travail. »
Les chercheurs ont démontré comment un modèle spécialement conçu pouvait exploiter la faille pour contourner Jinja, un moteur de création de modèles basé sur Python utilisé pour structurer les interactions entre les utilisateurs et les LLM, les protections sandbox et exécuter du code dans le processus de diffusion du modèle. L’attaque pourrait exposer les fournisseurs d’hébergement d’IA qui permettent aux clients de télécharger et d’exécuter leurs propres modèles, donnant potentiellement aux attaquants un pied dans l’infrastructure de traitement des demandes de plusieurs clients, ajoute le message.
Le désaccord porte sur la question de savoir si l’interprète devrait être responsable d’empêcher les fuites du bac à sable. Alors que RunSybil affirme que la faille crée des risques pour l’infrastructure d’inférence de l’IA, le PSRT affirme que l’exécution de code Python non fiable dans un bac à sable ne relève pas du modèle de menace de sécurité de CPython.
Exploiter le mécanisme de gestion de type de Python
« Le bug que nous avons découvert abuse de la gestion des types génériques par CPython pour réaliser une évasion », a écrit Houle. « Nous l’avons exploité en utilisant des objets que les sandbox rendent disponibles dans chaque modèle, même dans des contextes sandbox vides. »
Les chercheurs ont découvert que CPython peut utiliser une liste de paramètres mise en cache même après qu’un objet a été modifié via un rappel. Lorsque l’interpréteur recherche ensuite un paramètre nouvellement introduit dans la liste d’origine, il peut recevoir un index invalide. Une assertion conçue pour détecter la condition est désactivée dans les versions normales, permettant à l’interpréteur d’accéder à la mémoire en dehors des limites attendues.
RunSybil a utilisé ce comportement pour récupérer des références à des objets Python que le bac à sable était censé garder inaccessibles.
« Alors qu’une adresse invalide fait généralement planter l’interpréteur, une adresse pointant vers un objet Python actif utile donne à notre rappel une référence à cet objet (même lorsque le bac à sable n’a jamais l’intention de l’exposer) », a écrit Houle.
Les chercheurs ont ensuite utilisé les références d’objets récupérées pour accéder aux classes et fonctions Python nécessaires à la construction du code exécutable.
Les modèles de modèles malveillants permettent l’exécution de code
Pour démontrer l’attaque, RunSybil a modifié le modèle Qwen2.5-0.5B-Instruct en insérant un fichier chat_template.jinja de porte dérobée. Lorsque le modèle était chargé et utilisé via un moteur de service d’inférence tel que vLLM, le modèle permettait l’exécution de code arbitraire dans le processus de service.
« Sortir du bac à sable des modèles de chat et exécuter du code représente un risque pour la chaîne d’approvisionnement qui met en danger les fournisseurs d’inférences, les développeurs de bibliothèques et les utilisateurs de modèles », a écrit Houle.
Les chercheurs ont déclaré avoir partagé des exploits de validation de principe avec plusieurs fournisseurs d’inférence prenant en charge les fonctionnalités BYOM (Bring-your-own-model), qui permettent aux clients de télécharger des modèles à partir de sources externes.
Python conteste la classification des vulnérabilités
RunSybil a révélé le problème à CPython, au Pallets Project, qui gère Jinja, et à Hugging Face. Les chercheurs ont déclaré avoir rencontré des points de vue contradictoires sur le projet qui devrait résoudre le problème sous-jacent.
« Les évasions de tels sandbox sont donc en dehors de notre modèle de menace de sécurité et devraient être traitées par les responsables du logiciel de sandboxing concerné », a déclaré l’équipe.
L’équipe a également contesté la suggestion de RunSybil selon laquelle il n’y avait pas de processus de remédiation coordonné. Il a indiqué que les chercheurs avaient soumis le rapport par courrier électronique plutôt que via le canal privé de signalement des vulnérabilités GitHub de CPython.
Correctif rétroporté sur trois branches Python
RunSybil a soumis un correctif à CPython, qui a été fusionné dans la branche de développement principale le 14 août. Selon le PSRT, le correctif a également été rétroporté vers les branches 3.13, 3.14 et 3.15 en tant que correctif de bogue régulier plutôt qu’un correctif de sécurité.
La distinction est importante car RunSybil avait fait part de ses inquiétudes quant au fait que le correctif n’atteindrait pas toutes les versions de Python prises en charge.
Les chercheurs ont déclaré que l’absence de rétroportage vers Python 3.12 pourrait retarder l’adoption du correctif dans les déploiements d’infrastructure d’IA.
« Avec des parties importantes de l’écosystème de l’IA toujours solidement alignées sur Python 3.12, nous pourrions ne pas voir l’adoption organique de nos correctifs de sécurité de la mémoire avant la fin de 2028, lorsqu’ils atteindront leur date de fin de vie », a écrit Houle. Les chercheurs recommandent aux fournisseurs d’hébergement d’IA de traiter le code en bac à sable, les moteurs de modèles et les évaluateurs d’expressions comme des contrôles de sécurité au mieux, plutôt que de s’appuyer sur eux comme des limites de sécurité autonomes.
