Como obtivemos acesso root ao Copilot

• Em abril de 2025, o Copilot Enterprise foi atualizado com um sandbox Python em tempo real (baseado em Jupyter Notebook), tornando possível a execução de código no backend
• Pela sintaxe %command do Jupyter Notebook, era fácil executar código arbitrário no sistema subjacente, e também comandos Linux como o usuário ubuntu (ambiente miniconda)
• Havia uma vulnerabilidade de segurança em que o caminho /app/miniconda/bin era gravável pelo usuário ubuntu e tinha prioridade no $PATH do root, permitindo sobrescrever comandos importantes como pgrep
• Isso foi explorado para obter privilégios de root, mas o interior do contêiner era fortemente isolado, então não foi possível escapar do contêiner, nem houve vazamento adicional de informações
• A vulnerabilidade foi reportada em abril e corrigida em julho com risco moderado; os pesquisadores foram apenas incluídos na lista de reconhecimento, sem recompensa

---

Análise da vulnerabilidade do sandbox Jupyter do Microsoft Copilot Enterprise

Visão geral do ambiente Jupyter do Copilot Enterprise

• Desde abril de 2025, o Copilot Enterprise passou a usar um sandbox Python baseado em Jupyter Notebook
• Os usuários podem executar comandos de sistema Linux pela sintaxe %command do Jupyter
• O ambiente roda sobre miniconda com privilégios do usuário ubuntu, sem binário sudo
• Era possível explorar amplamente variáveis de ambiente, rede, sistema de arquivos e informações de processos

Funcionamento e estrutura interna do contêiner

• O Copilot é semelhante ao sandbox do ChatGPT, mas usa kernel mais recente e Python 3.12
• Processos principais: Jupyter Notebook, goclientapp escrito em Go (executando na porta 6000), httpproxy etc.
• A rede tinha apenas loopback e uma interface link-local limitada ativadas
• O sistema de arquivos usa OverlayFS com base no caminho /legion, e há scripts customizados em /app

Download e manipulação de arquivos

• Arquivos de texto e de saída de comandos podiam ser baixados normalmente, mas arquivos binários corriam risco de corrupção, exigindo codificação em base64
• Os arquivos ficam em /mnt/data, e links externos de download são gerados no formato de URL de blob

Estrutura do goclientapp/httpproxy

• goclientapp: executa no ambiente Jupyter o código recebido externamente pelo endpoint /execute (formato JSON) e retorna o resultado
• httpproxy: faz proxy do tráfego HTTP de saída do Jupyter (desativado com ENABLE_EGRESS=false)

Vulnerabilidade no script entrypoint.sh

• No entrypoint.sh, script de entrada do contêiner, vários serviços (goclientapp, httpproxyapp) rodam com privilégios do usuário ubuntu
• Apenas keepAliveJupyterSvc.sh permanece em execução contínua como root
• Na linha 28, o comando pgrep -f "jupyter notebook --ip=0.0.0.0 --port=8888" é executado de acordo com a prioridade dos diretórios em $PATH
• /app/miniconda/bin aparece antes de /usr/bin no PATH tanto do root quanto do usuário ubuntu → isso permite substituir arbitrariamente comandos como pgrep

Processo de obtenção de root e limitações

• O atacante criou um script pgrep malicioso em /app/miniconda/bin, fazendo com que o entrypoint.sh o executasse periodicamente com privilégios de root
• Esse script lia o arquivo /mnt/data/in, executava seu conteúdo como comando de shell e salvava o resultado em /mnt/data/out
• Com isso, foi possível obter privilégios de root dentro do contêiner, mas não acessar informações sensíveis como arquivos em /root, logs etc., nem escapar do contêiner
• O contêiner já tinha correções aplicadas para vários cenários de breakout

Resposta da Microsoft e resultado

• 18 de abril de 2025: a Eye Security reportou a vulnerabilidade ao MSRC
• 25 de julho de 2025: a Microsoft a classificou como risco moderado (moderate severity), aplicou a correção, encerrou o caso e incluiu os pesquisadores na lista de reconhecimento (sem pagamento de bug bounty)

Referências e apêndice

• A Eye Security é uma empresa europeia de cibersegurança que oferece monitoramento de ameaças 24/7, resposta a incidentes, seguro cibernético etc.

• Casos de intrusão em serviços internos da Microsoft (incluindo Entra OAuth), entre eles esta vulnerabilidade, serão apresentados na BlackHat USA 2025

• Linha do tempo

  • 18 de abril de 2025 – Reportado ao MSRC
  • 25 de julho de 2025 – Correção aplicada, caso encerrado e blog publicado

[GN⁺]

Comentários do Hacker News

• Entendi que o ponto central dessa vulnerabilidade era que, por meio de um truque, foi possível executar código com privilégios de root, apesar de o design originalmente pretender conceder apenas permissões de usuário comum dentro do contêiner. Porém, na prática, o próprio contêiner era tão rigidamente isolado que não havia nem acesso à rede nem possibilidade de escape, então a única coisa que dava para fazer com privilégios de root era quebrar o próprio contêiner
  • Dou crédito à Microsoft por ter configurado a segurança de forma realmente rigorosa. A maioria das empresas não isola nesse nível de perfeição
  • Não sei exatamente como esse contêiner foi implementado. A Microsoft usa uma abordagem padrão (Azure container-apps session) para isolar o sandbox de Python, e espero que este recurso também use isso ou algo semelhante
  • Acho um pouco estranho que o Copilot às vezes se recuse a executar código e às vezes permita. Fico curioso sobre qual é exatamente o objetivo até esse ponto
  • Hoje em dia, vulnerabilidades se acumulam como uma pilha, então dizer que “o contêiner é seguro” significa apenas que o atacante ainda não encontrou a falha. Escape de contêiner e de VM já são vetores de ataque conhecidos, e um pequeno erro, como uma configuração incorreta ou um bug em um driver virtio, pode ser suficiente para romper tudo. Este caso é, de fato, um resultado importante
• Quando vi um título como “How We Rooted Copilot”, achei que tivessem comprometido a VM principal do Copilot de verdade, mas na realidade foi apenas a obtenção de privilégios de root dentro de um contêiner de sandbox de Python extremamente restrito. Um título mais preciso seria “How We Rooted the Copilot Python Sandbox”
  • Dá para resumir como “elevação de privilégio de usuário comum para root em um sandbox totalmente isolado”. Na prática, o resultado quase não tem utilidade, mas justamente por isso mostra o quanto o sandbox contribui para a defesa
• É possível ver o processo completo de invasão aqui
• Eu tinha entendido esse caso como uma fuga do sandbox de Python e comprometimento até o contêiner. Imagino que seja por isso que a Microsoft classificou a gravidade da vulnerabilidade como moderada
• Talvez eu esteja deixando passar alguma coisa, mas não seria possível tentar uma conexão externa, nem que fosse passando pela rede local? Fico curioso se a Microsoft realmente não tinha risco de exfiltração de dados ou de ataques adicionais ao permitir root nesse tipo de contêiner para clientes
  • Quando a OpenAI lançou o recurso de interpretador Python, a situação era parecida. O acesso à rede externa era bloqueado, e o mais interessante que se encontrava eram alguns arquivos internos de configuração e algumas informações sobre como os desenvolvedores programavam. Este caso é praticamente igual
• Como saber se a resposta dada pelo Copilot é real ou pura alucinação? Eu trabalho lá e nunca vi um processo assim. Como referência, encontrei um script chamado keepAliveJupyterSvc.sh em um repositório público
  • Esse repositório e seus contribuidores realmente pertencem à MS/Azure e estão desenvolvendo um serviço de execução de código Python em contêiner. Não sei por que isso foi parar em uma conta pessoal. Dizem que é um fork de um projeto do Office, mas não consegui achar o original
  • Pode não ser alucinação. O código do Copilot pode ter sido gerado a partir do dataset de treinamento do GitHub
  • Isso parece mesmo alucinação. A maioria dos chatbots é basicamente um gerador de tokens. Eles não executam de fato um programa para responder; só geram tokens na GPU, convertem em inglês e enviam
• Já houve quem dissesse que LLMs antigos treinavam com documentos privados de empresas e acabavam expondo bem os segredos corporativos. Hoje em dia, parece que a maior parte dos dados já foi filtrada
  • Nunca vi um caso em que um LLM memorizasse um único dado que apareceu por acaso, nem um caso real de grande volume de dados privados sendo usado em treinamento. Então isso me parece irrealista. A alucinação do LLM só pode fazer parecer, à primeira vista, que houve vazamento de segredo
  • Pela minha experiência, os segredos de uma empresa normalmente não significam muita coisa para outra empresa
  • Fico curioso se existem exemplos concretos desse tipo de caso. Nunca vi nenhum
  • Antigamente, até empresas (não técnicas) adotavam isso sem diretrizes e acabavam gerando conteúdo fora do propósito. Por exemplo, uma empresa de boba (bubble tea) lançou um LLM gratuito e sem cadastro, e eu cheguei a usá-lo para gerar alguns scripts bash antes de existir a versão gratuita do ChatGPT
  • Gostaria de saber a fonte disso
• Na prática, isso nem parece ser uma vulnerabilidade. O objetivo desse sistema é justamente executar código dentro de um contêiner
  • Claro, isso só faz sentido sob a premissa de que o contêiner está isolado
• Talvez tivesse sido ainda mais fácil contornar isso passando o binário do sudo em base64 para o Copilot e depois usando-o
  • Nesse caso, também seria necessário mudar o dono do arquivo para root
• Reportei a vulnerabilidade para a Microsoft, ela foi classificada como moderada, não rendeu bug bounty e recebi apenas um acknowledgement. Não entendo muito bem como uma empresa desse tamanho não paga nem recompensa. Fico em dúvida se algo ruim não pode surgir numa situação dessas
  • Essencialmente, não foi obtido nada. Mesmo com root, só foi possível explorar uma parte do contêiner que antes era inacessível, mas não havia arquivos em /root nem logs úteis. Todas as técnicas de escape conhecidas já estavam corrigidas. Se a Microsoft passasse a recompensar cada método contornado como esse, não teria fim; então, se não houver risco real, até dá para entender não haver recompensa separada
  • Eu realmente não entendo por que as pessoas enviam relatórios de bug de graça para uma megacorporação de trilhões de dólares
  • Se a Microsoft não vai pagar, pelo menos poderia mandar algum swag. Dar brindes legais para hackers vira publicidade natural e pode até despertar vontade de trabalhar lá. Eles precisariam aproveitar melhor a cultura da comunidade hacker
  • Mesmo obtendo “root”, na prática não se ganha nada. Foram feitas várias tentativas e não houve resultado algum