Hackearam o sandbox Python do Gemini e vazaram parte do código-fonte

• Lupin e Justin investigaram o sandbox Python da prévia do Gemini no LLM bugSWAT 2024 da Google, em Las Vegas, e extraíram /usr/bin/entry/entry_point e a estrutura interna de arquivos; por essa falha, ganharam o prêmio de Most Valuable Hacker
• O sandbox era baseado em gVisor e GRTE, com a rede externa bloqueada, mas o código do usuário podia percorrer o sistema de arquivos com o módulo os, permitindo exfiltrar binários internos em chunks de saída no console
• Como o entry_point, de 579 MB, gerava timeout quando impresso diretamente, eles criaram chunks de 10 MB com seek() e codificação base64, repetiram as requisições com o Caido Automate e remontaram o arquivo localmente
• A análise com Binwalk revelou o diretório google3 e código Python relacionado ao sandbox do Gemini; diferente do código cuja exposição pública havia sido aprovada, classification.proto e várias definições de proto de segurança incluíam informações internas confidenciais de forma não intencional
• Também foi confirmado que o sandbox se conectava por RPC a ferramentas como Google Flights e que havia a possibilidade de acessar um sandbox de agente com mais privilégios, mas o suspeito handler interno de leitura de arquivos não podia ser usado por RPC e só podia ser chamado externamente

---

bugSWAT 2024 e acesso à prévia do Gemini

• Lupin e Justin tiveram acesso antecipado à prévia da próxima atualização do Gemini no evento LLM bugSWAT da Google em Las Vegas, em 2024
• A equipe do Google forneceu documentos com novos recursos e comportamentos pretendidos, e o objetivo dos pesquisadores era explorar e testar as funcionalidades da perspectiva de um atacante
• Ao começar com o prompt simples run hello world in python3, o Gemini gerou código e ofereceu na interface o botão Run in Sandbox
• Como resultado dessa pesquisa de vulnerabilidade, os dois receberam o título de Most Valuable Hacker naquele bugSWAT de Las Vegas

Estrutura básica do sandbox Python do Gemini

• Na época, o Gemini oferecia um Python Sandbox Interpreter para executar, dentro do ambiente do Gemini, código Python gerado por IA ou scripts escritos diretamente pelo usuário
• O sandbox era construído com base no gVisor do Google e no GRTE (Google Runtime Environment)
  • gVisor é um kernel em espaço de usuário que intercepta chamadas de sistema entre aplicações conteinerizadas e o sistema operacional hospedeiro
  • Em vez de depender apenas do isolamento tradicional no nível do SO, ele implementa um subconjunto minimizado de funcionalidades do kernel para reduzir a superfície de ataque
• Os pesquisadores trataram a fuga do sandbox gVisor como um problema separado e de alta dificuldade, e uma escape do sandbox poderia render uma recompensa de até US$ 100 mil
• Em vez de escapar do sandbox, a abordagem desta vez foi procurar se havia, dentro dele, dados que não deveriam ser expostos externamente
• A principal limitação era que o sandbox só podia executar um binário Python compilado sob medida

Mapeamento do sistema de arquivos e descoberta do entry_point

• Pelo frontend, era possível reescrever completamente o código Python e executar uma versão arbitrária dentro do sandbox
• Não dava para abrir um shell, mas o binário Python customizado incluía o módulo os, o que permitia mapear o sistema de arquivos
• Os pesquisadores escreveram uma função Python que listava recursivamente arquivos e diretórios e imprimia tamanho e permissões
• O resultado da chamada lslR("/usr") revelou um arquivo binário em /usr/bin/entry/entry_point
• Esse arquivo tinha 579 MB e se tornou o alvo principal da análise posterior

Como o binário foi exfiltrado sem rede

• Quando tentaram codificar o entry_point em base64 e imprimi-lo diretamente no frontend, o sandbox travou e acabou dando timeout
• Todas as tentativas de exfiltração externa via TCP, HTTP ou DNS falharam, e o sandbox parecia totalmente isolado da rede externa
• Com as chamadas externas bloqueadas, os pesquisadores optaram por vazar o binário em partes pela saída do console
• Usando seek() para mover a posição no binário, eles liam, codificavam em base64 e imprimiam chunks de 10 MB
• Usaram o Caido como proxy para capturar as requisições ao sandbox e os resultados, e repetiram os envios com o recurso Automate
  • Automate é um recurso para enviar muitas requisições e alterar rapidamente parâmetros específicos
  • Depois de reunir todos os chunks em base64, remontaram o arquivo completo localmente

Resultado da análise do entry_point

• O comando file identificou o arquivo como um binário dinâmico no formato ELF 64-bit LSB shared object, x86-64, version 1 (SYSV)
• Na saída do comando strings, apareceram várias referências a google3, apontando para o repositório interno do Google
• Essas referências sugeriam a presença de caminhos de dados internos e trechos de código, mostrando que o binário continha vestígios de software proprietário do Google
• O Binwalk forneceu a pista decisiva
  • Ele extraiu toda a estrutura de arquivos de dentro do binário
  • O resultado revelou o layout do sandbox e seus componentes internos

Diretório google3 e código Python relacionado ao Gemini

• Dentro do diretório extraído pelo Binwalk havia um diretório google3, com subdiretórios como assistant, base, devtools, file, google, net, pyglib, testing, third_party e util
• No diretório assistant, foi encontrado código Gemini relacionado a RPC usado para tratar solicitações de ferramentas como YouTube, Google Flights e Google Maps
• Em especial, sob google3/assistant/boq/lamda/execution_box/, havia arquivos Python ligados à execução no sandbox, processamento de imagens, uso de ferramentas e interface RPC
• Em google3/assistant/boq/lamda/execution_box/images/py_interpreter.py, havia código com uma string que parecia ser usada para detectar dumps não autorizados de scripts
  • A string era "3AVp#dzcQj$U?uLOj+Gl]GlY<+Z8DnKh"
• Em revisão posterior, a inclusão desse código Python interno do Google3 foi tratada como uma escolha cuja exposição pública antes do lançamento havia sido aprovada pela equipe de segurança do Google
• Embora esse código contivesse elementos que pareciam mecanismos anti-dump, a própria exposição pública estava aprovada

Estrutura de RPC entre o sandbox e ferramentas do Google

• Uma análise mais profunda confirmou que o sandbox se comunicava com servidores externos do Google para obter dados de serviços como o Google Flights
• Essa comunicação era implementada por classes Python em google3.assistant.boq.lamda.execution_box.sandbox_interface
• Funções como _set_reader_and_writer configuravam handlers de leitura e escrita para RPC
  • O comportamento padrão aparentava usar /dev/fd/3 e /dev/fd/4
• run_tool(name, operation_id, parameters) recebia o nome da ferramenta, o ID da operação e os parâmetros, montava um RunToolRequest e o enviava como requisição RPC
• As funções serializavam os dados em formato compatível com protobuf, gravavam no descritor de arquivo local 5 e liam a resposta no descritor 7
• Usando os protos encontrados no grande binário, os pesquisadores conseguiram montar mensagens trocadas com o servidor RPC e chamar diretamente ferramentas do Google

Sandbox de agente e diferenças de privilégio

• Nem todos os sandboxes podiam acessar o mesmo conjunto de serviços do Google
• A diferença dependia de o sandbox ter sido criado pelo frontend para executar código-fonte Python ou por um agente do Google
• A equipe do Google mostrou como base de pesquisa do Gemini o trabalho REACT: SYNERGIZING REASONING AND ACTING IN LANGUAGE MODELS
• A abordagem ReAct alterna entre a geração de trilhas de raciocínio pelo modelo de linguagem e a execução de ações específicas
  • O modelo cria um plano ao resolver o problema e interage com fontes externas para obter os dados necessários
  • O framework é apresentado para tarefas como perguntas e respostas, checagem de fatos, jogos baseados em texto e navegação na web
• Se um usuário perguntasse pelo voo mais cedo entre Toronto e Nova York, o Gemini poderia seguir aproximadamente este fluxo
  • Interpretar a intenção do usuário como uma busca de voos
  • Planejar código Python que se conecte à ferramenta Google Flights
  • Gerar código para buscar voos de YYZ para JFK entre hoje e a próxima semana e ordenar por data
  • Criar um sandbox com as permissões necessárias e executar o código
  • Processar a saída e responder ao usuário

Experimentos com prompt injection secundária e limitações

• Os pesquisadores testaram se poderiam aplicar uma injeção secundária de prompt na fase de planejamento do Gemini para acessar um sandbox com mais privilégios
• Em testes feitos com ajuda da equipe de segurança do Google, verificou-se que, dependendo de fatores probabilísticos como seed de geração e temperature, às vezes era possível chegar a um ambiente que parecia um sandbox com mais privilégios
• Nesse contexto, o sandbox com mais privilégios significava um ambiente capaz de usar dois novos descritores de arquivo para acessar funcionalidades de extensão
  • Os descritores de arquivo em si sempre existiam, mas nem sempre havia algo efetivamente em listen neles
  • Quando um agente chamava o sandbox, era possível observar chamadas de extensão de serviços do Google e interagir com a API
  • Ao acessar pelo interpretador Python, essa funcionalidade de extensão não ficava disponível
• Os pesquisadores suspeitaram que um handler específico de mensagens pudesse permitir leitura de arquivos na infraestrutura interna do Google e esperavam potencial para um P0
• Após revisão da equipe de segurança do Google, confirmou-se que o handler suspeito não podia ser usado por RPC e só podia ser chamado externamente
• Embora os experimentos tenham sido limitados, a execução de código poderia abrir as seguintes possibilidades
  • Reliability: executar código pode acionar comportamentos de forma mais consistente
  • Chaining/Complexity: controle de múltiplas ferramentas ou ajuste de parâmetros pode ser montado de forma mais complexa do que com texto
  • Tool Output Poisoning: torna mais eficaz a tentativa de manipular a saída de ferramentas
  • Leaks: exposição de partes ocultas do ambiente pode trazer vantagens adicionais

Os arquivos proto realmente expostos

• Os pesquisadores confirmaram que era possível exfiltrar arquivos proto de várias maneiras
• Arquivos proto são arquivos Protocol Buffer que funcionam como um blueprint da estrutura de mensagens e da forma como o sistema troca informações
• Depois de executar strings entry_point > stringsoutput.txt, eles pesquisaram por Dogfood e encontraram partes de protos internos
• Parte do conteúdo extraído incluía descrições de metadados de protos altamente sensíveis
  • Não incluía dados de usuários em si
  • Tratava-se de categorias internas usadas pelo Google para classificar dados de usuários
• Dogfood é a prática do Google de usar internamente seus próprios produtos e protótipos antes do lançamento público para testar e melhorar
• Um dos arquivos expostos era privacy/data_governance/attributes/proto/classification.proto
  • Esse arquivo trata de como os dados são classificados internamente no Google
  • Também incluía referências a documentação relacionada, mas esses documentos são confidenciais e não são de acesso público

Exposição de definições internas de proto de segurança

• Na mesma saída de strings, também apareceram vários arquivos proto internos que não deveriam ser públicos
• O comando cat stringsoutput.txt| grep '\.proto' | grep 'security' revelou os seguintes caminhos de arquivos sensíveis
  • 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
• Ao verificar security/credentials/proto/authenticator.proto nas strings do binário, foi possível ver que esses dados de fato estavam expostos

Por que os protos estavam no binário

• A equipe de segurança do Google revisou o conteúdo do sandbox e havia aprovado a divulgação pública correspondente
• Porém, o pipeline de build que compilava o binário do sandbox tinha uma etapa automática que adicionava arquivos proto de segurança ao binário quando entendia que isso poderia ser necessário para aplicar regras internas
• Neste caso, essa etapa não era necessária, mas acabou incluindo protos internos altamente confidenciais de forma não intencional
• Os pesquisadores reportaram isso como bug porque sabiam que o Google trata esse tipo de proto como informação sigilosa que não deve ser pública
• Identificar e reportar exposições sutis como essa exige compreensão profunda das regras de negócio e das prioridades de segurança da organização-alvo

Conclusão e implicações práticas

• Sistemas avançados de IA em pré-lançamento precisam ser testados a fundo não só quanto ao comportamento funcional, mas também quanto aos artefatos internos
• Mesmo um sandbox aparentemente simples pode criar caminhos inesperados de exposição quando se conecta a múltiplas funcionalidades de extensão
• Quando vários componentes operam juntos, pequenas omissões podem abrir novos caminhos para problemas
• Neste caso, fez-se a distinção entre código interno com exposição pública aprovada e protos confidenciais incluídos de forma não intencional; o segundo ponto foi o núcleo real do relatório de segurança
• Em ambientes que combinam agentes de IA, execução em sandbox, chamada de ferramentas e RPC interno, é preciso revisar não só o isolamento de execução, mas também os ativos internos do sandbox e os artefatos gerados no build