Comment nous avons obtenu les privilèges root sur Copilot

• En avril 2025, Copilot Enterprise a été mis à jour avec un sandbox Python en temps réel (basé sur Jupyter Notebook), rendant possible l’exécution de code côté back-end
• Grâce à la syntaxe %command de Jupyter Notebook, il était facile d’exécuter du code arbitraire sur le système sous-jacent, et les commandes Linux pouvaient aussi être lancées en tant qu’utilisateur ubuntu (environnement miniconda)
• Une faille de sécurité existait, car le chemin /app/miniconda/bin était accessible en écriture par l’utilisateur ubuntu et avait aussi la priorité dans le $PATH de root, ce qui permettait d’écraser des commandes clés comme pgrep
• Cette faille a été exploitée pour obtenir les privilèges root, mais l’intérieur du conteneur était fortement isolé, rendant toute évasion du conteneur impossible, sans fuite d’informations supplémentaire
• Après un signalement en avril, la faille a été corrigée en juillet avec un niveau de risque modéré, et le chercheur a seulement été ajouté à la liste des remerciements, sans récompense

---

Analyse de la vulnérabilité du sandbox Jupyter de Microsoft Copilot Enterprise

Vue d’ensemble de l’environnement Jupyter de Copilot Enterprise

• Depuis avril 2025, un sandbox Python basé sur Jupyter Notebook a été introduit dans Copilot Enterprise
• Les utilisateurs peuvent exécuter des commandes système Linux via la syntaxe %command de Jupyter
• L’environnement s’exécute avec les privilèges de l’utilisateur ubuntu sur une base miniconda, sans binaire sudo
• Il est possible d’explorer de nombreux éléments comme les variables d’environnement, le réseau, le système de fichiers et les informations sur les processus

Fonctionnement interne et structure du conteneur

• Copilot est similaire au sandbox de ChatGPT, mais utilise un noyau plus récent et Python 3.12
• Processus principaux : Jupyter Notebook, goclientapp écrit en Go (exécuté sur le port 6000), httpproxy, etc.
• Le réseau n’active que le loopback et des interfaces link-local limitées
• Le système de fichiers repose sur OverlayFS avec le chemin /legion comme base, et des scripts personnalisés sont présents dans /app

Téléchargement et manipulation de fichiers

• Les fichiers texte et les sorties de commandes peuvent être téléchargés normalement, mais les fichiers binaires risquent d’être corrompus, ce qui nécessite un encodage base64
• Les fichiers se trouvent dans /mnt/data et un lien de téléchargement externe est généré sous forme d’URL blob

Structure de goclientapp/httpproxy

• goclientapp : exécute dans l’environnement Jupyter le code (au format JSON) reçu de l’extérieur via l’endpoint /execute, puis renvoie le résultat
• httpproxy : sert de proxy pour le trafic HTTP sortant depuis Jupyter (désactivé avec ENABLE_EGRESS=false)

Vulnérabilité du script entrypoint.sh

• Dans entrypoint.sh, le script de point d’entrée du conteneur, plusieurs services (goclientapp, httpproxyapp) s’exécutent avec les privilèges de l’utilisateur ubuntu
• Seul keepAliveJupyterSvc.sh continue à s’exécuter en root
• À la ligne 28, la commande pgrep -f "jupyter notebook --ip=0.0.0.0 --port=8888" s’exécute selon la priorité des répertoires présents dans le $PATH
• /app/miniconda/bin apparaît avant /usr/bin dans le PATH à la fois pour root et pour l’utilisateur ubuntu → il est donc possible de remplacer arbitrairement des commandes comme pgrep

Processus d’obtention des privilèges root et limites

• L’attaquant a créé un script pgrep malveillant dans /app/miniconda/bin, ce qui amenait entrypoint.sh à exécuter périodiquement ce fichier avec les privilèges root
• Ce script lisait le fichier /mnt/data/in, l’exécutait comme commande shell, puis enregistrait le résultat dans /mnt/data/out
• Cette méthode a permis d’obtenir les privilèges root dans le conteneur, mais l’accès à des informations sensibles comme les fichiers de /root ou les logs restait impossible, et aucune évasion du conteneur n’était possible
• Le conteneur avait déjà été corrigé contre divers scénarios de breakout

Réponse de Microsoft et résultat

• 18 avril 2025 : Eye Security a transmis un rapport de vulnérabilité au MSRC
• 25 juillet 2025 : Microsoft a classé la faille avec une sévérité modérée (moderate severity), a corrigé le problème, clos le dossier et ajouté le chercheur à la liste des remerciements (sans bug bounty)

Références et annexe

• Eye Security est une entreprise européenne de cybersécurité proposant surveillance des menaces 24/7, réponse aux incidents et cyberassurance

• Les cas d’intrusion dans des services internes de Microsoft, y compris cette faille (Entra OAuth, etc.), doivent être présentés à BlackHat USA 2025

• Chronologie

  • 18 avril 2025 – Signalement au MSRC
  • 25 juillet 2025 – Correctif, clôture du dossier et publication du blog

[GN⁺]

Commentaires sur Hacker News

• Je comprends que le cœur de cette vulnérabilité est qu’au lieu de n’accorder à l’origine que des privilèges d’utilisateur standard à l’intérieur du conteneur, une astuce permettait en fait d’exécuter du code avec les privilèges root. Mais en pratique, le conteneur lui-même était tellement bien isolé qu’il n’avait même pas d’accès réseau et qu’il était impossible d’en sortir, si bien qu’obtenir root ne permettait guère plus que de casser son propre conteneur
  • Il faut reconnaître que Microsoft a vraiment verrouillé la sécurité de façon très rigoureuse. La plupart des entreprises n’isolent pas les choses à ce point
  • Je ne sais pas exactement comment ce conteneur est implémenté. Microsoft utilise une méthode standard (Azure container-apps session) pour isoler le sandbox Python, donc j’espère que cette fonctionnalité utilisait ça ou quelque chose de similaire
  • Je trouve un peu étrange que Copilot refuse parfois l’exécution de code et l’autorise à d’autres moments. Je me demande jusqu’où ils cherchent précisément à aller
  • De nos jours, les vulnérabilités s’empilent comme une pile, donc dire qu’« un conteneur est sûr » signifie surtout que l’attaquant n’a pas encore trouvé la faille. Les évasions de conteneur ou de VM sont déjà des vecteurs d’attaque connus, et une simple petite erreur comme une mauvaise configuration ou un bug dans un pilote virtio peut suffire à tout percer. Dans ce contexte, ce cas a une vraie importance
• En voyant un titre comme « How We Rooted Copilot », je pensais qu’ils avaient réellement compromis la VM principale de Copilot, alors qu’en réalité ils ont seulement obtenu les privilèges root dans un conteneur sandbox Python extrêmement limité. Un titre plus exact serait « How We Rooted the Copilot Python Sandbox »
  • On pourrait résumer cela par « élévation de privilèges réussie d’un utilisateur standard à root dans un sandbox totalement isolé ». En pratique, le résultat n’a pas beaucoup d’intérêt, mais c’est au contraire un bon exemple de l’efficacité défensive du sandbox
• On peut voir l’intégralité du processus de piratage ici
• J’avais compris cet incident comme une évasion du sandbox Python puis une compromission du conteneur lui-même. C’est probablement dans ce contexte que Microsoft a classé la gravité de la vulnérabilité comme moderate
• Il y a peut-être quelque chose qui m’échappe, mais ne serait-il pas possible d’essayer d’établir une connexion réseau externe, ne serait-ce qu’en passant par le réseau local ? Je me demande si Microsoft était vraiment certain qu’autoriser root dans ce type de conteneur n’impliquait aucun risque d’exfiltration de données ou d’attaque supplémentaire
  • Quand OpenAI avait publié sa fonctionnalité d’interpréteur Python, la situation était similaire. L’accès réseau externe était bloqué, et les seules choses un peu intéressantes étaient quelques fichiers de configuration internes et quelques indices sur la manière dont les développeurs codent. Ce cas est en fait pratiquement identique
• Comment savoir si la réponse donnée par Copilot est réelle ou si c’est une hallucination ? Je travaille là-bas, et je n’ai jamais vu un tel processus. À titre de référence, j’ai trouvé dans un dépôt public un script nommé keepAliveJupyterSvc.sh
  • Ce dépôt et ses contributeurs appartiennent bien à MS/Azure et travaillent sur un service d’exécution de code Python dans un conteneur. Je ne sais pas pourquoi cela se retrouve sur un compte personnel. On dit que c’est un fork d’un projet Office, mais je n’ai pas trouvé l’original
  • Ce n’est peut-être pas une hallucination. Le code de Copilot a peut-être été généré à partir du dataset d’entraînement de GitHub
  • Pour moi, ça ressemble vraiment à une hallucination. Les chatbots ne sont pour la plupart que des générateurs de tokens. Ils ne lancent pas réellement un programme pour produire une réponse ; ils génèrent des tokens sur GPU, les convertissent en anglais et les renvoient
• On disait autrefois que les premiers LLM étaient entraînés sur des documents d’entreprise privés et exposaient facilement des secrets d’entreprise. Aujourd’hui, il semble que les données soient pour la plupart filtrées
  • Les LLM ne mémorisent pas vraiment des données apparues une seule fois par hasard, et je n’ai jamais vu de cas où une grande quantité de données privées aurait réellement été intégrée à l’entraînement. Donc cela me paraît irréaliste. Les hallucinations de LLM peuvent seulement donner l’apparence d’une fuite de secrets crédible
  • D’après mon expérience, les secrets d’entreprise n’ont souvent pas grand intérêt pour d’autres entreprises
  • Je me demande s’il existe des exemples concrets de ce type de cas. Je n’en ai jamais vu
  • À une époque, même des entreprises (non techniques) lançaient ce genre de chose sans aucune directive, ce qui menait parfois à la génération de contenus hors sujet. Par exemple, une entreprise de boba (bubble tea) avait lancé un LLM gratuit sans inscription, et je m’en suis servi pour générer quelques scripts bash avant même la sortie de la version gratuite de ChatGPT
  • J’aimerais bien connaître la source
• Cela ne ressemble pas vraiment à une vulnérabilité. Le but même de ce système est précisément de faire exécuter du code dans un conteneur
  • Bien sûr, cela n’a de sens que si l’on part du principe que le conteneur reste isolé
• Il aurait peut-être été plus simple de contourner cela en donnant à Copilot le binaire sudo encodé en base64 puis en l’utilisant
  • Dans ce cas, il aurait aussi fallu changer le propriétaire du fichier en root
• Le problème a été signalé à Microsoft, classé moderate, et n’a donné lieu à aucune bug bounty, seulement à un acknowledgement. J’ai du mal à comprendre qu’une entreprise aussi grosse ne verse même pas de récompense. Je me demande comment cela peut ne pas mal finir un jour
  • En substance, cela n’a rien apporté. Obtenir root a seulement permis d’explorer une petite partie du conteneur qui restait de toute façon inaccessible ; il n’y avait aucun fichier dans /root, ni aucun log utile. Toutes les techniques d’évasion connues avaient déjà été corrigées. Si Microsoft devait récompenser chacune de ces méthodes de contournement, il n’y aurait pas de fin, donc je comprends dans une certaine mesure qu’il n’y ait pas de récompense particulière en l’absence de risque réel
  • Je ne comprends vraiment pas pourquoi des gens envoient gratuitement des bug reports à une multinationale valant des milliers de milliards
  • Si Microsoft ne veut pas payer, autant donner au moins du swag. Offrir de bons goodies aux hackers ferait naturellement de la pub et pourrait même donner envie d’y travailler. Ils devraient mieux exploiter la culture de la communauté hacker
  • Même en obtenant « root », on ne gagne en réalité rien du tout. Malgré plusieurs tentatives, cela n’a rien donné