Pirater le sandbox Python de Gemini pour exfiltrer une partie du code source

• Google organise des événements bugSWAT de red-teaming en amont pour renforcer la sécurité de l’IA, en donnant aux chercheurs l’occasion de tester en profondeur ses systèmes d’IA
• L’équipe qui avait remporté 50 000 $ en 2023 a cette fois encore découvert une nouvelle vulnérabilité dans Gemini, ce qui lui a valu le titre de « Most Valuable Hacker (MVH) »
• L’équipe de hackers a reçu de Google un accès et de la documentation sur une nouvelle fonctionnalité en preview de Gemini, afin de la tester sous l’angle de la sécurité
  • En demandant du code Python avec un prompt simple, un bouton « Run in Sandbox » était proposé
  • L’environnement sandbox de Gemini est un environnement d’exécution Python sécurisé conçu sur la base de gVisor et de GRTE de Google
• gVisor est un noyau en espace utilisateur créé par Google, une technologie qui renforce la sécurité en interceptant les appels système
  • L’environnement sandbox est complètement isolé, et il est très difficile d’en sortir
  • Mais il peut être possible d’exfiltrer des données depuis l’intérieur du sandbox
• En constatant que le sandbox fournissait la bibliothèque os, l’équipe a écrit du code Python pour explorer le système de fichiers
  • Elle a découvert un fichier binaire de 579 Mo à l’emplacement /usr/bin/entry/entry_point
• Comme afficher directement le binaire en base64 faisait planter le sandbox, il a été découpé et affiché par tranches de 10 Mo
  • Un outil appelé Caido a servi à collecter automatiquement tous les fragments puis à les reconstruire en local
  • L’analyse avec les commandes file, strings et binwalk a révélé la structure interne et des chemins internes de Google
• L’analyse binwalk a mis au jour un répertoire google3 contenant du code source Python interne
  • Dans le répertoire assistant, on trouvait du code lié aux RPC que Gemini utilise pour interagir avec des services Google comme YouTube ou Flights
  • Des chaînes destinées à empêcher le dump de certains scripts étaient présentes, mais l’équipe sécurité de Google a examiné le code en amont et a jugé sa divulgation acceptable

Analyse de la logique principale du sandbox

• Les appels aux services Google sont implémentés dans certaines classes écrites en Python
  • Par exemple, _set_reader_and_writer, run_tool, etc. communiquent avec les services Google via des descripteurs de fichiers
  • À l’intérieur du binaire, il est possible de construire directement des messages à partir de schémas protobuf et d’invoquer des outils
• Google a implémenté Gemini sur la base de l’article ReAct, afin qu’il génère lui-même plusieurs prompts et élabore un plan pour résoudre des problèmes complexes
  • Par exemple, si l’utilisateur demande « Horaires de vol Toronto → New York ? », Gemini choisit un outil et récupère les données en plusieurs étapes
  • En exploitant cette logique, l’équipe a tenté une prompt injection pour faire créer un sandbox avec davantage de privilèges
• Certains sandboxes peuvent accéder à des extensions Google, notamment des API RPC
  • Les extensions sont appelées via des FD toujours ouverts, et leur exploitation pourrait permettre un niveau d’accès système plus élevé
  • Il a été confirmé qu’un sandbox avancé pouvait être atteint dans certaines conditions, par exemple durant l’étape où Gemini élabore son plan

Fuite de fichiers proto sensibles

• Les fichiers Protocol Buffer (proto) servent à définir les données entre systèmes et contiennent des informations sensibles sur la structure interne
  • Après exécution de strings entry_point > stringsoutput.txt, une recherche sur la chaîne « Dogfood » a révélé de nombreux chemins de proto sensibles
  • Exemple : privacy/data_governance/attributes/proto/classification.proto → un fichier qui définit la façon dont Google classe les données utilisateur
• La commande cat stringsoutput.txt | grep '.proto' | grep 'security' a révélé une longue liste de fichiers proto sensibles liés à la sécurité
  • Exemples : security/thinmint/proto/core/thinmint_core.proto, security/credentials/proto/authenticator.proto, etc.

Pourquoi ces fichiers étaient-ils là ?

• L’équipe sécurité de Google avait approuvé à l’avance le contenu inclus dans le binaire du sandbox, mais un pipeline de build automatisé a ajouté des fichiers proto de sécurité inutiles
• Cela a conduit à l’exposition externe de fichiers de définition internes hautement sensibles
• Les hackers ont considéré qu’il s’agissait bien d’une vulnérabilité, au motif que ces fichiers sont traités comme des informations sensibles selon les propres critères de Google

Conclusion et retour d’expérience

• Les systèmes d’IA reposent sur de très nombreux éléments en interaction, si bien que des problèmes de sécurité inattendus surviennent fréquemment
• Même un simple sandbox peut communiquer avec des outils internes et voir ses privilèges varier dynamiquement, ce qui exige des tests très précis
• La collaboration avec l’équipe sécurité de Google a été utile, et l’expérience dans son ensemble a constitué une aventure aussi exigeante que passionnante

[GN⁺]

Avis Hacker News

• C’est le système sur lequel je travaille. N’hésitez pas à poser des questions. Tous les avis exprimés sont personnels et ne représentent pas ceux de mon employeur
• Super article. Ce n’est pas une grosse vulnérabilité, mais le fait que Google la prenne au sérieux montre une vraie conscience des enjeux de sécurité
  • Cela peut être pris au sérieux parce qu’il a été mentionné que certaines politiques internes de l’entreprise considèrent cela comme hautement confidentiel, mais on a davantage l’impression que c’est « techniquement considéré comme une vulnérabilité » qu’une faille évidente
• J’utilise une méthode similaire pour récupérer le code source interne de ChatGPT Code Interpreter dans un dépôt GitHub
  • C’est surtout utile pour suivre quels paquets Python sont disponibles (et dans quelles versions)
• Si c’était vraiment très confidentiel, tout ne serait sans doute pas sur GitHub
• La définition du hacking devient de plus en plus floue. Le sandbox remplit son rôle et aucune information sensible n’a fuité
• Exécuter la commande intégrée strings pour extraire quelques noms de fichiers depuis un binaire, c’est difficile à qualifier de hacking/cracking
  • Ironiquement, obtenir le code source de Gemini n’a peut-être pas beaucoup de valeur. En revanche, s’il avait trouvé ou pu accéder au corpus de préentraînement du modèle, là cela aurait été intéressant
• Il est intéressant de voir que Google est plutôt bien sécurisé. La plupart des entreprises ne feraient probablement pas aussi bien
• Je m’attendais à une fuite, mais cela reste une découverte et une analyse sympa
  • J’ai récemment réalisé à quel point des problèmes comme le prompt injection sur les LLMs sont importants
  • Comme je m’intéressais surtout aux LLMs personnels, je n’accordais pas beaucoup d’importance à ce genre de problème. Mais avec l’arrivée d’Operator et de Deep Research, j’ai fini par comprendre
  • Quand un agent IA personnel lit du contenu sur Internet ou regarde des images, il peut être vulnérable à des prompt injections introduites par des tiers
  • Il est intéressant d’imaginer un futur où une IA personnelle lit de fausses informations sur Internet et se fait pirater
• Article très intéressant
  • Il s’agit d’un fichier sur les catégories internes que Google utilise pour classer les données utilisateur
  • J’aimerais savoir de quel type de classification il s’agit. Par exemple, est-ce quelque chose comme « la personne est autiste », ou plutôt « ceci est le numéro de téléphone de l’utilisateur »
• Le sandbox a été piraté, mais rien n’a fuité. L’article reste divertissant