Vulnerabilidade Crítica no wasm2c Permite Execução de Comando Remoto

A vulnerabilidade crítica no wasm2c representa um cenário alarmante para a segurança de sistemas que executam código WebAssembly. O cerne do problema está na falha do wasm2c em verificar o retorno de calloc, uma função que aloca memória. Se calloc falhar (por exemplo, sob restrições de memória ou limites de endereço como RLIMIT_AS) e retornar NULL, o processo deveria ser interrompido. Contudo, o wasm2c continua a operar, usando uma tabela de funções baseada em NULL como se fosse válida.

Isso abre uma janela para um processo "guest" manipular endereços de memória do host. Uma tabela funcref de 64 GiB, mesmo que virtual, pode causar essa falha na alocação. Com a tabela corrompida, o "guest" consegue efetivamente realizar acessos a endereços que se resolvem para a memória do sistema hospedeiro. O PoC demonstrou a exploração vazando ponteiros importantes da biblioteca libc do host através do Global Offset Table (GOT), construindo uma entrada funcref falsa e, por fim, invocando system() para executar comandos arbitrários, como a criação de um arquivo. A correção envolve a verificação rigorosa de NULL após chamadas de alocação e a imposição de limites de tamanho para as tabelas.

A notícia de hoje sobre o wasm2c se conecta diretamente com discussões anteriores do CEVIU sobre a segurança do WebAssembly e vulnerabilidades de memória. Em 29 de abril de 2026, por exemplo, o CEVIU noticiou a descoberta de uma falha crítica de use-after-free no JavaScript do navegador Ladybird (GHSA-w89h-j2xg-c457), que também estava ligada ao crescimento de um SharedArrayBuffer do WebAssembly, gerando dangling pointers. Enquanto a falha do Ladybird era sobre desalocação incorreta, a do wasm2c é sobre a falha na alocação inicial e a falta de checagem. Ambos os casos, porém, sublinham a complexidade e os riscos de segurança inerentes à interação entre o WebAssembly e o ambiente de execução hospedeiro, especialmente no que tange ao gerenciamento de memória. Isso mostra que as vulnerabilidades de memória continuam sendo um ponto fraco persistente em ecossistemas que utilizam WASM, mesmo que os vetores de ataque específicos variem.

Esta vulnerabilidade é extremamente grave, alcançando o nível de execução remota de código (RCE) e quebra a principal promessa de isolamento do WebAssembly: a sandboxing. Se um programa "guest" em WebAssembly pode executar comandos no sistema hospedeiro, toda a arquitetura de segurança baseada nessa separação é comprometida. Isso é crítico para ambientes que utilizam WebAssembly para executar código não confiável, como plataformas de computação serverless, edge computing ou contêineres de aplicações. A capacidade de um atacante de vazar ponteiros libc e invocar system() transforma um módulo aparentemente inofensivo em um vetor de ataque completo. Empresas e desenvolvedores precisam urgentemente aplicar a correção e revisar suas estratégias de segurança para qualquer aplicação que use o wasm2c ou runtimes WebAssembly similares.