Vercel Sandbox resiste a ataques: 1285 relatórios, US$ 242 000 e uma falha no kernel do Linux

A Vercel encerrou o desafio de hacking em torno do Vercel Sandbox, um ambiente de nuvem para execução isolada de código. Em duas semanas, pesquisadores enviaram 1285 relatórios, e a Vercel pagou US$ 242 000 em recompensas. Nenhum relatório mostrou acesso a dados de clientes. Ainda assim, a descoberta mais séria não estava no código da Vercel, mas na base que sustenta boa parte das nuvens: uma vulnerabilidade zero-day na pilha de rede do kernel do Linux.

Zero-day no terceiro dia

O principal relatório chegou no terceiro dia do programa. Paulos Yibelo (pwn.ai), pesquisador da HackerOne, trabalhava a partir de um sandbox comum, sem privilégios especiais. Ele encontrou um defeito na pilha de rede do kernel do Linux: pacotes especialmente montados, enviados de dentro da microVM, permitiam realizar três ataques diferentes.

• Vazamento de memória do host pela rede. A memória da máquina, compartilhada pelo sandbox com outros inquilinos, ia parar nos pacotes que o guest enviava à internet. O vazamento era contínuo, enquanto o guest continuasse transmitindo tráfego. O ataque foi demonstrado em sandboxes de produção da Vercel.
• Travamento do host. Dois pacotes bastavam para derrubar a máquina e, com ela, todos os sandboxes que rodavam ali.
• Execução de código no host. A mesma falha permitia executar comandos com privilégios totais de administrador e escapar da fronteira de isolamento.

O pesquisador reproduziu o travamento e a execução de código em máquinas próprias com KVM e Firecracker, replicando a configuração do Vercel Sandbox.

Quase todos os grandes provedores de nuvem isolam seus clientes justamente nessa camada do kernel, então o risco se estende à infraestrutura compartilhada. A Vercel afirma que trabalhou com o pesquisador, com a AWS e com outros parceiros para acelerar a correção. Em paralelo, Yibelo contatou os mantenedores do kernel e preparou com eles candidatos a patch. Eles passam por revisão fechada, os CVEs ainda não foram atribuídos e os detalhes não serão divulgados por ora. A empresa revelou a existência da vulnerabilidade porque o assunto já vinha sendo discutido publicamente.

Visão de dentro: o estagiário e a Trail of Bits

Além da caça pública a recompensas, a Vercel fez revisões internas com acesso total ao código-fonte e contratou a Trail of Bits. Nem todas as descobertas vieram de fora. O estagiário da Vercel Marcos Hernanz encontrou um vazamento entre inquilinos na camada de armazenamento Linux device-mapper: qualquer sandbox podia ler blocos de disco reaproveitados de sandboxes excluídos anteriormente.

A Trail of Bits dedicou quatro semanas de engenharia, com dois especialistas alocados. Eles tiveram acesso total aos repositórios e a dois ambientes de teste corporativos. O resultado foram 20 achados, cada um testado, confirmado e associado a um ponto específico do código. A revisão de arquitetura mostrou que a fronteira de virtualização é sólida. Cada sandbox roda em uma microVM Firecracker própria, com kernel guest dedicado, o modelo de dispositivos é deliberadamente mínimo, e nenhum guest compartilha o kernel em execução nem com o host nem com outro inquilino.

Três conclusões estruturais

Os auditores fizeram três recomendações, e a Vercel afirma que cumpriu todas.

• Eliminar a confiança no guest. A camada de controle aceitava valores retornados pelo software dentro da microVM, e qualquer valor desse tipo, na prática, é informado pelo inquilino. Agora, tudo que cruza a fronteira é calculado no servidor ou assinado com uma chave inacessível ao guest.
• Uma política, um árbitro. O controle de tráfego de saída estava espalhado por subsistemas, e cada um interpretava a política de rede por conta própria, com decisões que nem sempre coincidiam. Agora há um único procedimento de canonização para cada tipo de dado e um único componente para cada decisão, e as conexões são reavaliadas quando a política muda.
• Partir do princípio de que o próximo zero-day vai aparecer. A proteção em torno de cada sandbox foi reforçada para limitar o dano caso o software de virtualização seja comprometido. Os kernels dos hosts são atualizados, a virtualização aninhada está desativada, e o jailer do Firecracker inicia cada processo da microVM com privilégios reduzidos.

Lições práticas para quem executa código de terceiros

Sandboxes para agentes de IA e código gerado estão se tornando parte padrão da stack, e esse caso mostra onde o risco realmente está. A microVM com kernel próprio funcionou: mesmo com uma vulnerabilidade no host, ninguém acessou dados de clientes. Mas o isolamento não elimina a necessidade de atualizar os kernels dos hosts nem de desconfiar de tudo que volta do guest.

Equipes que constroem seus próprios sandboxes ou escolhem um provedor devem verificar três pontos: se a camada de controle aceita dados do guest sem validação, se a interpretação das políticas de rede está duplicada em componentes diferentes e com que rapidez o provedor aplica patches de kernel. Os detalhes dos CVEs sairão depois da publicação das correções, e será preciso conferir as versões de kernel e as configurações do Firecracker em uso.