Ein Teil des Quellcodes wurde durch Hacken von Geminis Python-Sandbox offengelegt

• Lupin und Justin untersuchten bei Googles LLM bugSWAT 2024 in Las Vegas die Python-Sandbox der Gemini-Vorschau, extrahierten /usr/bin/entry/entry_point sowie die interne Dateistruktur und wurden für diese Schwachstelle mit dem Titel Most Valuable Hacker ausgezeichnet
• Die Sandbox basierte auf gVisor und GRTE, und das externe Netzwerk war blockiert. Da jedoch Benutzercode mit dem Modul os das Dateisystem durchlaufen konnte, ließen sich interne Binärdateien über Konsolen-Ausgabe-Chunks exfiltrieren
• Die 579 MB große entry_point ließ sich nicht direkt ausgeben, da sonst ein Timeout auftrat. Daher wurden mit seek() und Base64-Kodierung 10-MB-Chunks erzeugt, per wiederholten Anfragen mit Caido Automate abgerufen und lokal wieder zusammengesetzt
• Eine Analyse mit Binwalk legte das Verzeichnis google3 und Python-Code im Zusammenhang mit der Gemini-Sandbox offen. Anders als der zur Veröffentlichung freigegebene Code waren classification.proto und mehrere Security-Proto-Definitionen unbeabsichtigt enthaltene vertrauliche interne Informationen
• Es zeigte sich, dass die Sandbox per RPC mit Tools wie Google Flights verbunden war und möglicherweise Zugang zu privilegierteren Agent-Sandboxes bestand. Der verdächtigte interne File-Read-Handler war jedoch nicht per RPC nutzbar und nur extern aufrufbar

---

bugSWAT 2024 und Zugriff auf die Gemini-Vorschau

• Lupin und Justin erhielten beim Google-Event LLM bugSWAT 2024 in Las Vegas frühen Zugriff auf eine Vorschau des nächsten Gemini-Updates
• Das Google-Team stellte Dokumentation zu neuen Funktionen und beabsichtigtem Verhalten bereit, und das Ziel der Forschenden war es, die Funktionen aus Angreiferperspektive zu untersuchen und zu testen
• Mit dem einfachen Prompt run hello world in python3 begann Gemini, Code zu erzeugen, und bot in der Oberfläche den Button Run in Sandbox an
• Für diese Schwachstellenforschung erhielten die beiden bei diesem bugSWAT in Las Vegas den Titel Most Valuable Hacker

Grundstruktur der Gemini-Python-Sandbox

• Gemini bot damals einen Python Sandbox Interpreter, der von der KI erzeugten Python-Code oder direkt von Nutzern geschriebene Skripte innerhalb der Gemini-Umgebung ausführen konnte
• Die Sandbox basierte auf Googles gVisor und GRTE (Google Runtime Environment)
  • gVisor ist ein Userspace-Kernel, der Systemaufrufe zwischen containerisierten Anwendungen und dem Host-Betriebssystem abfängt
  • Statt sich nur auf klassische Isolation auf Betriebssystemebene zu verlassen, implementiert es eine minimierte Teilmenge von Kernel-Funktionen, um die Angriffsfläche zu verkleinern
• Die Forschenden betrachteten einen Escape aus der gVisor-Sandbox als separates Problem mit hohem Schwierigkeitsgrad; für einen Sandbox-Escape hätte es ein Bounty von bis zu 100.000 US-Dollar geben können
• Dieser Ansatz zielte jedoch nicht auf einen Escape ab, sondern darauf, innerhalb der Sandbox nach Daten zu suchen, die nicht nach außen gelangen sollten
• Eine zentrale Einschränkung war, dass in der Sandbox nur ein benutzerdefiniert kompiliertes Python-Binary ausgeführt werden konnte

Dateisystem-Mapping und Entdeckung von entry_point

• Im Frontend ließ sich der Python-Code vollständig umschreiben, sodass in der Sandbox beliebige Varianten ausgeführt werden konnten
• Eine Shell ließ sich nicht starten, aber das benutzerdefinierte Python-Binary enthielt das Modul os, wodurch sich das Dateisystem abbilden ließ
• Die Forschenden schrieben eine Python-Funktion, die rekursiv Dateien und Verzeichnisse auflistete und Größe sowie Berechtigungen ausgab
• Beim Aufruf von lslR("/usr") fanden sie eine Binärdatei unter /usr/bin/entry/entry_point
• Diese Datei war 579 MB groß und wurde zum Kern der weiteren Analyse

Wie die Binärdatei ohne Netzwerk exfiltriert wurde

• Der direkte Versuch, entry_point Base64-kodiert im Frontend auszugeben, ließ die Sandbox hängen und endete schließlich in einem Timeout
• Exfiltrationsversuche über TCP, HTTP und DNS scheiterten sämtlich; die Sandbox schien vollständig vom externen Netzwerk isoliert zu sein
• Da ausgehende Verbindungen blockiert waren, entschieden sich die Forschenden dafür, die Binärdatei über die Konsolenausgabe in Stücken herauszuschleusen
• Mit seek() wurde die Leseposition in der Binärdatei verschoben, die Daten wurden Base64-kodiert und als 10-MB-Chunks ausgegeben
• Mit Caido als Proxy wurden die Sandbox-Aufrufe und Ergebnisse abgefangen, und mit der Automate-Funktion wurden die Requests wiederholt gesendet
  • Automate ist eine Funktion, mit der sich große Mengen an Requests senden und bestimmte Parameter schnell variieren lassen
  • Nachdem alle Base64-Chunks gesammelt waren, wurde die gesamte Datei lokal rekonstruiert

Ergebnisse der entry_point-Analyse

• Der Befehl file identifizierte die Datei als dynamisch gelinkte Binärdatei im Format ELF 64-bit LSB shared object, x86-64, version 1 (SYSV)
• In der Ausgabe von strings tauchten mehrfach Verweise auf google3 auf, also auf Googles internes Repository
• Diese Verweise deuteten auf interne Datenpfade und Codefragmente hin und zeigten, dass die Binärdatei Spuren proprietärer Google-Software enthielt
• Binwalk lieferte den entscheidenden Hinweis
  • Es extrahierte die vollständige Dateistruktur aus der Binärdatei
  • Das Ergebnis legte das Layout der Sandbox und interne Komponenten offen

Das Verzeichnis google3 und Python-Code mit Bezug zu Gemini

• In dem mit Binwalk extrahierten Verzeichnis befand sich ein Ordner google3 mit Unterverzeichnissen wie assistant, base, devtools, file, google, net, pyglib, testing, third_party und util
• Im Verzeichnis assistant wurde RPC-bezogener Gemini-Code gefunden, der zur Verarbeitung von Tool-Anfragen für YouTube, Google Flights und Google Maps verwendet wurde
• Insbesondere unter google3/assistant/boq/lamda/execution_box/ lagen Python-Dateien zu Sandbox-Ausführung, Bildverarbeitung, Tool-Nutzung und RPC-Schnittstellen
• In google3/assistant/boq/lamda/execution_box/images/py_interpreter.py befand sich Code mit einer Zeichenfolge, die wie eine Erkennung für unautorisierte Skript-Dumps wirkte
  • Die Zeichenfolge lautete "3AVp#dzcQj$U?uLOj+Gl]GlY<+Z8DnKh"
• Bei einer späteren Prüfung wurde festgehalten, dass die Einbindung dieses Python-Codes aus dem internen Google3 von Googles Security-Team für eine Offenlegung vor Release freigegeben worden war
• Der Code enthielt zwar Elemente, die wie Anti-Dumping-Mechanismen wirkten, seine öffentliche Sichtbarkeit war jedoch genehmigt

RPC-Struktur zwischen Sandbox und Google-Tools

• Eine tiefere Analyse zeigte, dass die Sandbox mit externen Google-Servern kommunizierte, um Daten aus Google-Diensten wie Google Flights abzurufen
• Diese Kommunikation wurde über eine Python-Klasse in google3.assistant.boq.lamda.execution_box.sandbox_interface umgesetzt
• Funktionen wie _set_reader_and_writer konfigurierten Reader- und Writer-Handles für RPC
  • Das Standardverhalten schien /dev/fd/3 und /dev/fd/4 zu verwenden
• run_tool(name, operation_id, parameters) erzeugte aus Tool-Name, Operations-ID und Parametern ein RunToolRequest und leitete es als RPC-Anfrage weiter
• Die Funktionen serialisierten Daten in ein protobuf-kompatibles Format, schrieben sie auf den lokalen File-Descriptor 5 und lasen Antworten von File-Descriptor 7
• Mithilfe der in der großen Binärdatei gefundenen Protos konnten die Forschenden Nachrichten für den RPC-Server erstellen und Google-Tools direkt aufrufen

Agent-Sandboxes und Unterschiede bei Berechtigungen

• Nicht alle Sandboxes konnten auf denselben Satz von Google-Diensten zugreifen
• Der Unterschied hing davon ab, ob die Sandbox vom Frontend zur Ausführung von Python-Quellcode erzeugt worden war oder von einem Google-Agenten
• Das Google-Team verwies auf die Forschung, auf der Gemini basierte: REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS
• Der ReAct-Ansatz beschreibt eine Struktur, in der ein Sprachmodell abwechselnd Denkschritte erzeugt und bestimmte Aktionen ausführt
  • Das Modell erstellt bei der Problemlösung einen Plan und interagiert mit externen Quellen, um benötigte Daten zu beschaffen
  • Vorgestellt wird es als Framework für Aufgaben wie Frage-Antwort, Faktenprüfung, textbasierte Spiele und Webnavigation
• Fragt ein Nutzer etwa nach dem frühesten Flug zwischen Toronto und New York, könnte Gemini grob wie folgt arbeiten
  • Es interpretiert die Absicht des Nutzers als Flugsuche
  • Es plant Python-Code zur Anbindung an das Google-Flights-Tool
  • Es erzeugt Code, der Flüge von YYZ nach JFK von heute bis zur nächsten Woche sucht und nach Datum sortiert
  • Es erstellt eine Sandbox mit den nötigen Berechtigungen und führt den Code aus
  • Es verarbeitet die Ausgabe und antwortet dem Nutzer

Experimente mit sekundärer Prompt Injection und ihre Grenzen

• Die Forschenden testeten, ob sich über sekundäre Prompt Injection in Geminis Planungsphase Zugriff auf privilegiertere Sandboxes erreichen ließ
• Bei Tests mit Unterstützung von Googles Security-Team zeigte sich, dass je nach probabilistischen Faktoren wie Seed und Temperature gelegentlich eine Umgebung erreichbar war, die wie eine privilegiertere Sandbox wirkte
• Mit dieser privilegierteren Sandbox war eine Umgebung gemeint, in der zwei neue File-Deskriptoren für den Zugriff auf Erweiterungsfunktionen nutzbar waren
  • Die File-Deskriptoren selbst waren immer vorhanden, lauschten aber nicht immer tatsächlich
  • Wenn ein Agent die Sandbox aufrief, konnte er Erweiterungsaufrufe an Google-Dienste überwachen und mit der API interagieren
  • Vom Python-Interpreter aus waren diese Erweiterungsfunktionen jedoch nicht zugänglich
• Die Forschenden vermuteten, ein bestimmter Message-Handler könne Dateizugriffe innerhalb von Googles interner Infrastruktur erlauben, und hofften daher auf ein mögliches P0
• Nach Prüfung durch Googles Security-Team stellte sich jedoch heraus, dass der verdächtige Handler nicht per RPC nutzbar und nur extern aufrufbar war
• Das Experiment war zwar begrenzt, aber Codeausführung konnte dennoch folgende Möglichkeiten eröffnen
  • Reliability: Mit ausgeführtem Code lassen sich Aktionen konsistenter auslösen
  • Chaining/Complexity: Steuerung mehrerer Tools oder Anpassung von Parametern lässt sich komplexer gestalten als nur mit Text
  • Tool Output Poisoning: Manipulationen von Tool-Ausgaben lassen sich gezielter versuchen
  • Leaks: Werden verborgene Teile der Umgebung sichtbar, kann das zusätzliche Vorteile bringen

Tatsächlich offengelegte Proto-Dateien

• Die Forschenden stellten fest, dass sich Proto-Dateien auf mehreren Wegen exfiltrieren ließen
• Proto-Dateien sind Protocol-Buffer-Dateien und dienen als Blaupause für Nachrichtenstrukturen und den Informationsaustausch eines Systems
• Nach Ausführung von strings entry_point > stringsoutput.txt und einer Suche nach Dogfood fanden sie Teile interner Protos
• Ein Teil der extrahierten Inhalte enthielt Metadatenbeschreibungen zu hochsensiblen Protos
  • Konkrete Nutzerdaten waren darin nicht enthalten
  • Es handelte sich um interne Kategorien, die Google zur Klassifizierung von Nutzerdaten verwendet
• Dogfood bezeichnet bei Google die Praxis, eigene Produkte und Prototypen intern vor öffentlicher Veröffentlichung zu nutzen, zu testen und zu verbessern
• Eine der offengelegten Dateien war privacy/data_governance/attributes/proto/classification.proto
  • Diese Datei behandelt, wie Daten intern bei Google klassifiziert werden
  • Sie enthielt auch Verweise auf zugehörige Dokumente, die vertraulich und nicht öffentlich zugänglich sind

Offenlegung interner Security-Proto-Definitionen

• In derselben strings-Ausgabe wurden mehrere interne Proto-Dateien sichtbar, die nicht öffentlich werden sollten
• Mit dem Befehl cat stringsoutput.txt| grep '\.proto' | grep 'security' erschienen unter anderem folgende sensiblen Dateipfade
  • 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
• Ein Blick auf security/credentials/proto/authenticator.proto in den Binär-Strings zeigte, dass diese Daten tatsächlich offengelegt waren

Warum die Protos in der Binärdatei landeten

• Googles Security-Team hatte den Inhalt der Sandbox geprüft und die öffentliche Offenlegung genehmigt
• In der Build-Pipeline zur Kompilierung des Sandbox-Binaries gab es jedoch einen automatischen Schritt, der Security-Proto-Dateien in die Binärdatei aufnahm, wenn dies für die Durchsetzung interner Regeln als notwendig eingestuft wurde
• In diesem Fall war dieser Schritt nicht erforderlich, wodurch am Ende hochvertrauliche interne Protos unbeabsichtigt enthalten waren
• Die Forschenden wussten, dass Google solche Protos als streng vertrauliche Informationen behandelt, die nicht öffentlich werden dürfen, und meldeten dies deshalb als Bug
• Solch subtile Offenlegungen lassen sich nur erkennen und melden, wenn man die Geschäftsregeln und Sicherheitsprioritäten der Zielorganisation sehr genau versteht

Fazit und praktische Implikationen

• Fortschrittliche KI-Systeme vor dem Release müssen nicht nur auf Funktionsverhalten, sondern auch auf interne Artefakte gründlich getestet werden
• Selbst eine simpel wirkende Sandbox kann unerwartete Offenlegungspfade schaffen, wenn sie mit mehreren Erweiterungsfunktionen verbunden ist
• Wenn mehrere Komponenten zusammenspielen, können kleine Auslassungen neue Problemwege erzeugen
• In diesem Fall wurde zwischen internem Code mit Freigabe zur Offenlegung und unbeabsichtigt enthaltenen vertraulichen Protos unterschieden; Letztere bildeten den eigentlichen Kern des Sicherheitsberichts
• In Umgebungen, in denen KI-Agenten, Sandbox-Ausführung, Tool-Aufrufe und internes RPC zusammenkommen, müssen nicht nur die Laufzeitisolation, sondern auch Assets innerhalb der Sandbox und Build-Artefakte überprüft werden