Wie wir Copilot gerootet haben

• Im April 2025 wurde Copilot Enterprise um eine Python-Sandbox in Echtzeit (auf Basis von Jupyter Notebook) erweitert, wodurch die Ausführung von Backend-Code möglich wurde
• Über die %command-Syntax von Jupyter ließ sich leicht beliebiger Code auf dem zugrunde liegenden System ausführen, und auch Linux-Befehle konnten als Benutzer ubuntu (in einer miniconda-Umgebung) ausgeführt werden
• Es bestand eine Sicherheitslücke, da der Pfad /app/miniconda/bin für den Benutzer ubuntu beschreibbar war und im $PATH von root ebenfalls priorisiert wurde, sodass sich wichtige Befehle wie pgrep überschreiben ließen
• Dies wurde ausgenutzt, um Root-Rechte zu erlangen, doch das Container-Innere war streng isoliert, sodass kein Container-Escape möglich war und auch keine weiteren Informationen offengelegt wurden
• Die Schwachstelle wurde nach einer Meldung im April im Juli als mittleres Risiko gepatcht; außer einem Eintrag in der Liste der Forschenden gab es keine Vergütung

---

Analyse der Schwachstelle in der Microsoft Copilot Enterprise Jupyter Sandbox

Überblick über die Copilot Enterprise Jupyter-Umgebung

• Seit April 2025 verfügt Copilot Enterprise über eine Python-Sandbox auf Basis von Jupyter Notebook
• Nutzer können über die %command-Syntax von Jupyter Linux-Systembefehle ausführen
• Die Umgebung läuft auf Basis von miniconda mit den Rechten des Benutzers ubuntu; ein sudo-Binary ist nicht vorhanden
• Umgebungsvariablen, Netzwerk, Dateisystem und Prozessinformationen lassen sich umfassend untersuchen

Verhalten und Struktur innerhalb des Containers

• Copilot ähnelt der ChatGPT-Sandbox, verwendet aber einen neueren Kernel und Python 3.12
• Wichtige Prozesse: Jupyter Notebook, das in Go geschriebene goclientapp (läuft auf Port 6000), httpproxy usw.
• Im Netzwerk sind nur Loopback und eine eingeschränkte Link-Local-Schnittstelle aktiv
• Das Dateisystem basiert auf OverlayFS mit dem Pfad /legion; unter /app existieren benutzerdefinierte Skripte

Download und Dateimanipulation

• Textdateien und Ausgabedateien von Befehlen lassen sich normal herunterladen; bei Binärdateien besteht Beschädigungsgefahr, daher ist eine Base64-Kodierung nötig
• Dateien liegen unter /mnt/data, und externe Download-Links werden in Form von Blob-URLs erzeugt

Struktur von goclientapp/httpproxy

• goclientapp: Führt Code aus, der extern über den Endpoint /execute hereinkommt (JSON-Format), in der Jupyter-Umgebung aus und gibt das Ergebnis zurück
• httpproxy: Proxy für ausgehenden HTTP-Traffic von Jupyter nach außen (derzeit deaktiviert mit ENABLE_EGRESS=false)

Schwachstelle im Skript entrypoint.sh

• Im Einstiegsskript des Containers, entrypoint.sh, werden mehrere Dienste (goclientapp, httpproxyapp) mit den Rechten des Benutzers ubuntu ausgeführt
• Nur keepAliveJupyterSvc.sh läuft weiterhin als root
• In Zeile 28 wird der Befehl pgrep -f "jupyter notebook --ip=0.0.0.0 --port=8888" gemäß der Priorität der Verzeichnisse im $PATH ausgeführt
• /app/miniconda/bin steht sowohl bei root als auch beim Benutzer ubuntu im PATH vor /usr/bin → Befehle wie pgrep konnten dadurch beliebig ersetzt werden

Weg zu Root-Rechten und seine Grenzen

• Ein Angreifer konnte unter /app/miniconda/bin ein bösartiges pgrep-Skript anlegen, das von entrypoint.sh periodisch mit Root-Rechten ausgeführt wurde
• Dieses Skript las die Datei /mnt/data/in, führte ihren Inhalt als Shell-Befehl aus und speicherte das Ergebnis in /mnt/data/out
• Auf diesem Weg gelang es zwar, innerhalb des Containers Root-Rechte zu erlangen, doch auf sensible Informationen wie Dateien unter /root oder Logs konnte nicht zugegriffen werden, und ein Container-Escape war ebenfalls nicht möglich
• Verschiedene Breakout-Szenarien im Container waren bereits gepatcht

Reaktion und Ergebnis bei Microsoft

• 18. April 2025: Eye Security meldet den Fehler an das MSRC
• 25. Juli 2025: Microsoft stuft die Schwachstelle als mittelschwer (moderate severity) ein, patcht sie und schließt den Fall; die Forschenden werden in die Liste aufgenommen (keine Bug-Bounty-Auszahlung)

Hinweise und Anhang

• Eye Security ist ein in Europa ansässiges Cybersecurity-Unternehmen und bietet unter anderem 24/7-Bedrohungsüberwachung, Incident Response und Cyber-Versicherung an

• Ein Vortrag zu Eindringfällen in interne Microsoft-Dienste (einschließlich Entra OAuth) mit dieser Schwachstelle ist für die BlackHat USA 2025 geplant

• Zeitachse

  • 18. April 2025 – An MSRC gemeldet
  • 25. Juli 2025 – Gepatcht und Fall geschlossen, Blog veröffentlicht

[GN⁺]

Hacker-News-Kommentar

• Der Kern dieser Schwachstelle besteht offenbar darin, dass sich mit einem Trick Code mit Root-Rechten ausführen ließ, obwohl das Design eigentlich nur normale Benutzerrechte innerhalb des Containers erlauben sollte. In der Praxis war der Container selbst jedoch so gründlich isoliert, dass weder Netzwerkzugriff möglich war noch ein Ausbruch, sodass man mit Root-Rechten letztlich nur den eigenen Container kaputtmachen konnte
  • Ich muss anerkennen, dass Microsoft die Sicherheit wirklich sehr gründlich konfiguriert hat. Die meisten Unternehmen isolieren nicht annähernd so perfekt
  • Ich weiß nicht genau, wie dieser Container implementiert war. Microsoft verwendet für die Isolation der Python-Sandbox den Standardansatz (Azure container-apps session); ich hoffe, dass diese Funktion ebenfalls darauf oder auf etwas Ähnlichem basiert
  • Es wirkt etwas merkwürdig, dass Copilot die Codeausführung manchmal verweigert und manchmal erlaubt. Ich frage mich, worauf genau das Zielsystem eigentlich hinauswill
  • Heutzutage stapeln sich Schwachstellen oft wie ein ganzer Stack, deshalb bedeutet „der Container ist sicher“ meist nur, dass der Angreifer die nächste Lücke noch nicht gefunden hat. Container-Escape und VM-Escape sind bekannte Angriffsmethoden, und schon ein kleiner Konfigurationsfehler oder ein Bug im virtio-Treiber kann reichen. In diesem Sinn ist der Fall durchaus relevant
• Bei einem Titel wie „How We Rooted Copilot“ dachte ich zuerst, sie hätten tatsächlich die zentrale VM von Copilot kompromittiert, aber in Wirklichkeit haben sie nur in einem extrem eingeschränkten Python-Sandbox-Container Root-Rechte erlangt. Der präzisere Titel wäre „How We Rooted the Copilot Python Sandbox“
  • Man könnte es als „Privilegieneskalation von normalem Benutzer zu Root in einer vollständig isolierten Sandbox“ zusammenfassen. Praktisch ist das kaum bedeutsam, aber gerade deshalb zeigt es, wie wirksam die Sandbox zur Verteidigung beiträgt
• Hier kann man den vollständigen Hacking-Prozess sehen
• Ich hatte den Vorfall so verstanden, dass sie aus der Python-Sandbox ausgebrochen und bis zum Container vorgedrungen sind. Vermutlich hat Microsoft die Schwere deshalb als moderat eingestuft
• Vielleicht übersehe ich etwas, aber wäre es nicht möglich, wenigstens über das lokale Netzwerk eine Verbindung nach außen zu versuchen? Ich frage mich, ob Microsoft Kunden in solchen Containern wirklich Root-Rechte geben konnte, ohne dabei ein Risiko für Datenabfluss oder weitere Angriffe zu schaffen
  • Als OpenAI früher die Python-Interpreter-Funktion veröffentlicht hat, war die Situation ähnlich. Externer Netzwerkzugriff war blockiert, und interessant waren allenfalls einige interne Konfigurationsdateien und ein paar Hinweise darauf, wie die Entwickler programmierten. Dieser Fall ist im Grunde derselbe
• Wie kann man wissen, ob die von Copilot gegebene Antwort echt ist oder bloß Halluzination? Ich arbeite dort, habe aber so einen Prozess noch nie gesehen. Zur Referenz: Ich habe im öffentlichen Repository ein Skript namens keepAliveJupyterSvc.sh gefunden
  • Das Repository und die Mitwirkenden scheinen tatsächlich zu MS/Azure zu gehören und an einem Dienst zur Ausführung von Python-Code im Container zu arbeiten. Warum das unter einem privaten Account hochgeladen wurde, weiß ich nicht. Es soll ein Fork eines Office-Projekts sein, aber ich konnte das Original nicht finden
  • Es muss keine Halluzination sein. Der Copilot-Code könnte aus dem GitHub-Trainingsdatensatz erzeugt worden sein
  • Das wirkt auf mich tatsächlich wie eine Halluzination. Chatbots sind größtenteils nur Token-Generatoren. Sie führen nicht wirklich ein Programm aus und antworten darauf, sondern erzeugen Tokens auf der GPU und schicken sie als englischen Text zurück
• Früher hieß es, dass ältere LLMs mit nicht öffentlichen Unternehmensdokumenten trainiert worden seien und deshalb Firmengeheimnisse preisgaben. Inzwischen scheint das meiste Datenmaterial bereinigt zu sein
  • Ich habe noch keinen Fall gesehen, in dem ein LLM große Mengen privater Daten tatsächlich gelernt hätte, und ich halte es auch für unrealistisch, dass es sich an einmalig auftauchende Daten erinnert. Deshalb denke ich, dass eher Halluzinationen nur so aussehen, als wären es echte Geheimnislecks
  • Nach meiner Erfahrung sind Firmengeheimnisse für andere Unternehmen oft gar nicht besonders interessant
  • Ich frage mich, ob es dafür konkrete Beispiele gibt. Ich habe selbst keine gesehen
  • Früher haben auch nichttechnische Unternehmen solche Systeme ohne Richtlinien eingeführt, sodass Inhalte außerhalb des eigentlichen Zwecks erzeugt wurden. Zum Beispiel hatte einmal eine Boba-Company ein kostenloses LLM ohne Registrierung, und ich habe dort noch vor der kostenlosen Version von ChatGPT ein paar Bash-Skripte erzeugen lassen und benutzt
  • Mich würde die Quelle interessieren
• Das wirkt praktisch gar nicht wie eine Schwachstelle. Genau dafür ist dieses System schließlich gebaut: Code in einem Container auszuführen
  • Natürlich ist das nur unter der Voraussetzung sinnvoll, dass der Container isoliert bleibt
• Es wäre vielleicht einfacher gewesen, Copilot den sudo-Binary als base64 zu geben und ihn dann auf diese Weise zu verwenden
  • Dann müsste man allerdings auch den Dateibesitzer auf root ändern
• Die Schwachstelle wurde Microsoft gemeldet, als moderat eingestuft, und es gab keine Bug-Bounty, sondern nur eine Danksagung. Ich verstehe nicht, wie ein so großes Unternehmen nicht einmal eine Belohnung zahlt. Ich frage mich, ob dabei langfristig nichts Schlechtes passieren kann
  • Im Kern hat man eigentlich nichts gewonnen. Mit Root-Rechten konnte man nur Teile des Containers untersuchen, auf die man vorher keinen Zugriff hatte, aber unter /root lagen keine Dateien und auch keine brauchbaren Logs. Alle bekannten Escape-Techniken waren bereits gepatcht. Wenn Microsoft jeden einzelnen solchen Umgehungsweg belohnen würde, hätte das kein Ende; deshalb kann ich nachvollziehen, dass man ohne echtes Risiko nicht gesondert vergütet
  • Ich verstehe wirklich nicht, warum Leute einem Billionen-Dollar-Konzern kostenlose Bugreports liefern
  • Wenn Microsoft schon kein Geld zahlt, dann wäre wenigstens etwas Swag sinnvoll. Gute Goodies für Hacker wären automatisch Werbung und könnten sogar Lust machen, dort zu arbeiten. Man sollte die Kultur der Hacker-Community besser nutzen
  • Selbst wenn man „root“ bekommt, gewinnt man in der Praxis nichts. Auch nach mehreren Versuchen kam nichts dabei heraus