Piratage du sandbox Python de Gemini et fuite d’une partie du code source

• Lors du LLM bugSWAT 2024 de Google à Las Vegas, Lupin et Justin ont analysé le sandbox Python de la préversion de Gemini, extrait /usr/bin/entry/entry_point ainsi que la structure des fichiers internes, et ont remporté le titre de Most Valuable Hacker grâce à cette vulnérabilité
• Le sandbox, basé sur gVisor et GRTE, bloquait l’accès au réseau externe, mais le code utilisateur pouvait parcourir le système de fichiers via le module os, ce qui permettait d’exfiltrer les binaires internes sous forme de fragments de sortie console
• Comme entry_point, un fichier de 579 Mo, provoquait un timeout lorsqu’il était imprimé directement, ils ont utilisé seek() et un encodage base64 pour créer des fragments de 10 Mo, puis ont répété les requêtes avec Caido Automate avant de les réassembler localement
• L’analyse avec Binwalk a révélé le répertoire google3 et du code Python lié au sandbox Gemini ; contrairement au code dont l’exposition publique avait été approuvée, classification.proto et plusieurs définitions proto de sécurité étaient des informations internes confidentielles incluses involontairement
• L’architecture reliant le sandbox à des outils comme Google Flights via RPC, ainsi que la possibilité d’accéder à des sandbox d’agent plus privilégiés, ont été confirmées, mais le handler de lecture de fichiers internes soupçonné n’était pas utilisable via RPC et ne pouvait être appelé que depuis l’extérieur

---

bugSWAT 2024 et accès à la préversion de Gemini

• Lupin et Justin ont obtenu un accès anticipé à la préversion de la prochaine mise à jour de Gemini lors de l’événement Google LLM bugSWAT 2024 à Las Vegas
• L’équipe Google a fourni une documentation décrivant les nouvelles fonctionnalités et les comportements attendus ; l’objectif des chercheurs était d’explorer et de tester ces fonctionnalités du point de vue d’un attaquant
• En commençant par un prompt simple, run hello world in python3, Gemini a généré du code et proposé un bouton Run in Sandbox dans l’interface
• À la suite de cette recherche sur la vulnérabilité, les deux chercheurs ont reçu le titre de Most Valuable Hacker lors de ce bugSWAT de Las Vegas

Structure de base du sandbox Python de Gemini

• À l’époque, Gemini proposait un Python Sandbox Interpreter permettant d’exécuter, dans l’environnement Gemini, du code Python généré par l’IA ou des scripts écrits directement par l’utilisateur
• Le sandbox reposait sur gVisor de Google et sur GRTE (Google Runtime Environment)
  • gVisor est un noyau en espace utilisateur qui intercepte les appels système entre les applications conteneurisées et le système d’exploitation hôte
  • Il réduit la surface d’attaque en implémentant un sous-ensemble minimal de fonctionnalités noyau, au lieu de s’appuyer uniquement sur l’isolation traditionnelle au niveau de l’OS
• Les chercheurs considéraient l’évasion du sandbox gVisor comme un problème difficile distinct, qui pouvait donner droit à une prime maximale de 100k $
• Leur approche ne consistait pas à s’échapper du sandbox, mais à chercher si des données qui ne devraient pas être exposées à l’extérieur s’y trouvaient
• La contrainte centrale était que le sandbox ne pouvait exécuter qu’un binaire Python compilé sur mesure

Cartographie du système de fichiers et découverte de entry_point

• Depuis le frontend, il était possible de réécrire entièrement le code Python et d’exécuter une version arbitraire dans le sandbox
• Il n’était pas possible de lancer un shell, mais le binaire Python personnalisé incluait le module os, ce qui permettait de cartographier le système de fichiers
• Les chercheurs ont écrit une fonction Python listant récursivement les fichiers et répertoires, puis affichant leur taille et leurs permissions
• L’appel lslR("/usr") a révélé un fichier binaire situé dans /usr/bin/entry/entry_point
• Ce fichier faisait 579 Mo et est devenu la cible principale de l’analyse qui a suivi

Méthode d’exfiltration du binaire sans réseau

• Lorsqu’ils ont tenté d’encoder directement entry_point en base64 et de l’afficher dans le frontend, le sandbox s’est figé avant de finir par expirer
• Les tentatives d’exfiltration externe via TCP, HTTP et DNS ont toutes échoué, et le sandbox semblait totalement isolé du réseau externe
• Les appels externes étant bloqués, les chercheurs ont choisi d’exfiltrer le binaire par morceaux via la sortie console
• Ils ont déplacé la position de lecture dans le binaire avec seek(), lu les données, les ont encodées en base64, puis les ont affichées par fragments de 10 Mo
• Ils ont utilisé Caido comme proxy pour capturer les requêtes d’appel au sandbox et leurs résultats, puis la fonction Automate pour renvoyer les requêtes en boucle
  • Automate permet d’envoyer un grand volume de requêtes et de modifier rapidement certains paramètres
  • Après avoir collecté tous les fragments base64, ils ont reconstitué le fichier complet en local

Résultats de l’analyse de entry_point

• La commande file a identifié le fichier comme un binaire lié dynamiquement au format ELF 64-bit LSB shared object, x86-64, version 1 (SYSV)
• La sortie de la commande strings contenait de nombreuses références à google3, le dépôt interne de Google
• Ces références suggéraient l’existence de chemins de données internes et de fragments de code, et montraient que le binaire contenait des traces de logiciels propriétaires de Google
• Binwalk a fourni l’indice décisif
  • Il a extrait toute une structure de fichiers depuis le binaire
  • Cette extraction a révélé la disposition du sandbox et ses composants internes

Répertoire google3 et code Python lié à Gemini

• Le répertoire extrait par Binwalk contenait un dossier google3, avec des sous-répertoires tels que assistant, base, devtools, file, google, net, pyglib, testing, third_party et util
• Dans le répertoire assistant, les chercheurs ont trouvé du code Gemini lié aux RPC utilisé pour traiter des requêtes d’outils comme YouTube, Google Flights et Google Maps
• En particulier, sous google3/assistant/boq/lamda/execution_box/, se trouvaient des fichiers Python liés à l’exécution du sandbox, au traitement d’images, à l’utilisation d’outils et aux interfaces RPC
• google3/assistant/boq/lamda/execution_box/images/py_interpreter.py contenait du code qui semblait inclure une chaîne destinée à détecter les dumps de scripts non autorisés
  • La chaîne était "3AVp#dzcQj$U?uLOj+Gl]GlY<+Z8DnKh"
• Après examen, l’inclusion interne Google3 de ce code Python a été considérée comme un choix dont l’exposition publique avant lancement avait été approuvée par la Google Security Team
• Ce code contenait des éléments ressemblant à des mécanismes anti-dump, mais son exposition publique elle-même avait été approuvée

Structure RPC entre le sandbox et les outils Google

• Une analyse plus poussée a confirmé que le sandbox communiquait avec des serveurs Google externes afin de récupérer des données de services Google comme Google Flights
• Cette communication était implémentée via des classes Python de google3.assistant.boq.lamda.execution_box.sandbox_interface
• Des fonctions comme _set_reader_and_writer configuraient les handles reader et writer utilisés pour les RPC
  • Le comportement par défaut semblait utiliser /dev/fd/3 et /dev/fd/4
• run_tool(name, operation_id, parameters) prenait le nom de l’outil, l’ID d’opération et les paramètres, créait une RunToolRequest et la transmettait sous forme de requête RPC
• Les fonctions sérialisaient les données dans un format compatible protobuf, les écrivaient dans le descripteur de fichier local 5, puis lisaient la réponse depuis le descripteur de fichier 7
• En utilisant les proto trouvés dans le gros binaire, les chercheurs ont pu créer des messages échangés avec le serveur RPC et appeler directement des outils Google

Sandbox d’agent et différences de privilèges

• Tous les sandbox n’avaient pas accès au même ensemble de services Google
• La différence dépendait du fait que le sandbox avait été créé par le frontend pour exécuter du code source Python, ou par un Google Agent
• L’équipe Google a présenté REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS comme l’une des recherches sur lesquelles Gemini s’appuyait
• L’approche ReAct consiste à alterner la génération de traces de raisonnement par le modèle de langage et l’exécution d’actions spécifiques
  • Le modèle résout un problème en construisant un plan et en interagissant avec des sources externes pour obtenir les données nécessaires
  • Elle est présentée comme un framework applicable à des tâches telles que les questions-réponses, la vérification factuelle, les jeux textuels et la navigation web
• Si un utilisateur demande le vol le plus tôt entre Toronto et New York, Gemini pourrait suivre grosso modo le flux suivant
  • Interpréter l’intention de l’utilisateur comme une recherche de vols
  • Planifier du code Python destiné à se connecter à l’outil Google Flights
  • Générer du code cherchant les vols entre YYZ et JFK, d’aujourd’hui à la semaine suivante, puis les triant par date
  • Créer un sandbox disposant des permissions nécessaires et y exécuter le code
  • Traiter le résultat de sortie et répondre à l’utilisateur

Expérience d’injection de prompt secondaire et limites

• Les chercheurs ont expérimenté une injection de prompt de second ordre dans la phase de planification de Gemini pour voir s’ils pouvaient accéder à un sandbox plus privilégié
• Avec l’aide de la Google Security Team, les tests ont montré qu’en fonction de facteurs probabilistes comme la graine de génération et la temperature, il était parfois possible d’accéder à un environnement ressemblant à un sandbox plus privilégié
• Ici, un sandbox plus privilégié désigne un environnement pouvant utiliser deux nouveaux descripteurs de fichiers donnant accès à des extensions
  • Les descripteurs de fichiers eux-mêmes existaient toujours, mais n’étaient pas toujours réellement en écoute
  • Lorsque l’agent appelait le sandbox, il pouvait surveiller les appels aux extensions de services Google et interagir avec l’API
  • Depuis l’interpréteur Python, ces extensions n’étaient pas accessibles
• Les chercheurs pensaient qu’un handler de messages spécifique pouvait permettre la lecture de fichiers dans l’infrastructure interne de Google, et espéraient une possible faille P0
• Après examen par la Google Security Team, il a été confirmé que ce handler suspect n’était pas utilisable via RPC et ne pouvait être appelé que depuis l’extérieur
• Bien que limitée, l’expérience montrait que l’exécution de code pouvait ouvrir les possibilités suivantes
  • Reliability : exécuter du code permet de déclencher des comportements de manière plus cohérente
  • Chaining/Complexity : le contrôle de plusieurs outils ou l’ajustement de paramètres peut être organisé de façon plus complexe qu’avec du texte
  • Tool Output Poisoning : la manipulation des sorties d’outils peut être tentée plus efficacement
  • Leaks : l’exposition de parties cachées de l’environnement peut procurer des avantages supplémentaires

Fichiers proto réellement exposés

• Les chercheurs ont confirmé qu’il était possible d’exfiltrer des fichiers proto de plusieurs façons
• Les fichiers proto sont des fichiers Protocol Buffer qui servent de plans pour définir la structure des messages du système et la manière dont les informations sont échangées
• Après avoir exécuté strings entry_point > stringsoutput.txt, ils ont recherché Dogfood et trouvé une partie de proto internes
• Certains contenus extraits incluaient des descriptions de métadonnées de proto très sensibles
  • Ils ne contenaient pas de données utilisateur elles-mêmes
  • Il s’agissait de catégories internes utilisées par Google pour classifier les données utilisateur
• Dogfood désigne chez Google la pratique consistant à utiliser en interne ses propres produits et prototypes avant leur lancement public afin de les tester et les améliorer
• L’un des fichiers exposés était privacy/data_governance/attributes/proto/classification.proto
  • Ce fichier traite de la manière dont les données sont classifiées en interne chez Google
  • Il contenait aussi des références à de la documentation associée, mais ces documents étaient confidentiels et non accessibles publiquement

Exposition de définitions proto de sécurité internes

• Dans la même sortie strings, plusieurs fichiers proto internes qui n’auraient pas dû être publics sont aussi apparus
• La commande cat stringsoutput.txt| grep '\.proto' | grep 'security' a fait apparaître les chemins de fichiers sensibles suivants
  • security/thinmint/proto/core/thinmint_core.proto
  • security/thinmint/proto/thinmint.proto
  • security/credentials/proto/authenticator.proto
  • security/data_access/proto/standard_dat_scope.proto
  • security/loas/l2/proto/credstype.proto
  • security/credentials/proto/end_user_credentials.proto
  • security/loas/l2/proto/usertype.proto
  • security/credentials/proto/iam_request_attributes.proto
  • security/util/proto/permission.proto
  • security/loas/l2/proto/common.proto
  • ops/security/sst/signalserver/proto/ss_data.proto
  • security/credentials/proto/data_access_token_scope.proto
  • security/loas/l2/proto/identity_types.proto
  • security/credentials/proto/principal.proto
  • security/loas/l2/proto/instance.proto
  • security/credentials/proto/justification.proto
• La présence de security/credentials/proto/authenticator.proto dans les chaînes du binaire permettait de constater que ces données avaient bien été exposées

Pourquoi ces proto se trouvaient dans le binaire

• La Google Security Team avait examiné le contenu du sandbox et approuvé sa disclosure publique
• Cependant, le pipeline de compilation du binaire du sandbox comportait une étape automatique qui ajoutait des fichiers proto de sécurité au binaire lorsqu’ils pouvaient être jugés nécessaires à l’application de règles internes
• Dans ce cas, cette étape n’était pas nécessaire, mais elle a finalement inclus involontairement des proto internes hautement confidentiels
• Les chercheurs savaient que Google considérait ces proto comme des informations très sensibles qui ne devaient pas être rendues publiques, et les ont donc signalés comme un bug
• Identifier et signaler ce type d’exposition subtile exige de bien comprendre les règles métier et les priorités de sécurité de l’organisation ciblée

Conclusion et enseignements pratiques

• Les systèmes d’IA avancés avant lancement doivent être testés en profondeur, non seulement sur le comportement de leurs fonctionnalités, mais aussi sur leurs artefacts internes
• Même un sandbox en apparence simple peut créer des chemins d’exposition inattendus lorsqu’il est relié à plusieurs extensions
• Lorsque plusieurs composants fonctionnent ensemble, un petit oubli peut ouvrir une nouvelle voie de problème
• Dans ce cas, le code interne dont l’exposition avait été approuvée a été distingué des proto confidentiels inclus involontairement, ces derniers constituant le cœur du signalement de sécurité réel
• Dans des environnements combinant agents IA, exécution en sandbox, appels d’outils et RPC internes, il faut examiner non seulement l’isolation d’exécution, mais aussi les actifs présents dans le sandbox et les artefacts de build