Um pesquisador saiu da máquina virtual e chegou a root no hospedeiro. O KVM ainda não tem CVE

O KVM é a peça que quase ninguém no mercado audita e da qual quase todo mundo depende. Ele está no kernel do Linux, serve de base para EC2, para Google Compute Engine, para provedor regional de nuvem, para o Firecracker, para o QEMU de quem roda virtualização em casa. Quando a falha é nessa camada, ela não é de um produto. É de um andar inteiro.

Por isso vale separar com cuidado o que foi confirmado do que ainda é vazio. As duas colunas importam, e misturar as duas é como esse tipo de notícia costuma causar mais dano do que informação.

O que foi confirmado e o que não foi

Esse é o estado real em 6 de outubro. Qualquer leitura além disso é especulação, inclusive a tranquilizadora.

Por que a camada é essa e não outra

A documentação de projeto do Firecracker é explícita sobre o modelo de confiança, e lê-la ajuda a entender o tamanho do problema. O isolamento é montado em camadas: o jailer prepara cgroup e chroot com privilégio, descarta o privilégio e executa o Firecracker como processo sem privilégio; filtros seccomp carregados por thread, antes de qualquer código do convidado rodar, limitam as chamadas de sistema ao mínimo; o cgroup contém recurso; o chroot restringe acesso a arquivo.

E a premissa de base, escrita na própria documentação, é que toda thread de vCPU deve ser considerada como executando código malicioso desde o instante em que começa. Ou seja: o projeto já parte do pior caso do lado do convidado. A primeira camada de isolamento é o KVM mais a fronteira de virtualização.

É aí que está o incômodo. Se a falha é no KVM, as camadas acima dela não estão no caminho. Seccomp restringe o que o processo Firecracker pede ao hospedeiro, não o que o convidado pede ao hipervisor. Uma vez que o pedido chega ao kernel do hospedeiro pela interface de virtualização e volta como escrita arbitrária, o jailer, o chroot e o cgroup já foram contornados por baixo.

US$ 50 mil por uma falha que o Google avalia em US$ 250 mil

Boa parte da discussão pública virou em torno do valor pago, e a comparação é legítima, desde que feita com o número certo. O kvmCTF, programa do próprio Google para falhas de KVM alcançáveis a partir da máquina virtual, publica a tabela:

A ressalva honesta é que o programa da Vercel nunca se propôs a precificar falha de KVM. O escopo dele era o Vercel Sandbox, com teto de US$ 50 mil por falha que permitisse ler ou alterar dado de outro inquilino, e janela de duas semanas. O pesquisador encontrou algo maior do que o escopo previa, e o teto do escopo foi o que se aplicou. Vale registrar as duas coisas: o valor seguiu a regra publicada, e a regra publicada ficou cinco vezes abaixo do que a casa que mantém o código paga pela mesma classe de falha.

Há um detalhe de contexto que diz muito sobre o momento. A Vercel justificou o programa pelos incidentes recentes de sandbox em OpenAI, Anthropic e Meta. O ponto do exercício era medir o que modelo de fronteira consegue e não consegue furar em guardrail real. O que apareceu foi uma falha na camada que ninguém no pacote de inquilinos controla.

O que fazer antes de existir correção

Sem CVE e sem patch, não há o que aplicar. Há o que verificar.

• Levantar onde a organização roda convidado não confiável sobre KVM. Isso inclui execução de código de cliente, sandbox de agente de IA, pipeline de build que roda código de terceiro e laboratório de análise de malware.
• Para carga de alto valor, separar inquilino por hospedeiro físico em vez de por microVM. É caro e é a única mitigação que não depende do hipervisor estar correto.
• Tratar o convidado como hostil no desenho de credencial: nenhuma credencial do hospedeiro, do metadado da instância ou de serviço de nuvem alcançável de dentro do convidado. Se a fuga acontecer, o prêmio precisa ser pequeno.
• Controle de saída de rede no nível do hospedeiro, não do convidado, e registro de conexão por microVM. É o que sobra de visibilidade quando a fronteira interna falha.
• Verificar agora quanto tempo leva para aplicar patch de kernel no parque de hospedeiros, incluindo janela de reinício e migração ao vivo. Quando a correção sair, essa medida vai definir o tempo de exposição.
• Acompanhar o aviso do fornecedor de nuvem e a lista de segurança do kernel. A divulgação coordenada de falha de KVM costuma vir com atualização simultânea nos provedores grandes, e sem aviso prévio para o cliente.

O que muda para quem opera no Brasil

• Provedor regional usa a mesma base. Boa parte da nuvem instalada no país roda KVM, direto ou via OpenStack. Quem contratou isolamento de ambiente em contrato local deveria perguntar ao fornecedor qual é o plano de atualização de hipervisor e qual a janela prevista.
• Quem vende execução de código de cliente tem exposição direta. Plataforma de automação, runner de CI, serviço que roda função de terceiro e qualquer produto que ofereça sandbox de agente estão na mesma classe de risco do caso descrito.
• Cláusula de multi-inquilino merece leitura. Em contrato de serviço, isolamento normalmente aparece como compromisso de resultado, sem detalhe de arquitetura. Vale pedir a descrição da fronteira e o que acontece em caso de falha dela.
• O exercício de mesa é simples e ninguém faz. Se amanhã sair um patch crítico de kernel para todos os hospedeiros de virtualização, em quantas horas ele entra, e quantos sistemas param durante o processo? Essa resposta não deveria ser descoberta no dia.

Leitura LATAMSEC

O que esse caso expõe não é o bug. É a dependência. Quando a conversa de segurança em nuvem se move para configuração, identidade e postura, fica fácil esquecer que embaixo de tudo existe uma fronteira única, escrita em C, dentro do kernel do Linux, que o cliente não controla, não audita e não consegue substituir. Ela funciona há anos, e isso é diferente de ser garantida.

Duas perguntas que valem agora, antes do relatório técnico.

Para quem desenha plataforma: o que um invasor com root no hospedeiro alcançaria hoje a partir de um dos seus nós de execução? Se a resposta inclui credencial de produção, o problema não é só o KVM.

Para quem compra nuvem: existe inventário de quais serviços críticos dividem hospedeiro físico com carga de terceiro? Sem esse mapa, não há como dimensionar o impacto quando a divulgação completa sair.