Protobuf JS expõe sistemas a uma vulnerabilidade de execução remota de código

Uma vulnerabilidade crítica à execução remota do código (RCE) saiu à luz em protobuf.js, a implementação em JavaScript do Protocol Buffers que usam milhares de projetos em Node.js. O problema chamou a atenção depois de pesquisadores partilharem um proof-of-concept público e os mantenedores publicarem adesivos; dada a popularidade da livraria — que registra perto de 50 milhões de downloads semanais — o achado merece atenção imediata por equipas de desenvolvimento e operações.

A falha reside em como a livraria gera código dinamicamente a partir dos esquemas. Em vez de construir estruturas seguras, protobuf.js concatena cadeias para formar funções JavaScript e as executa com o construtor Function (), aplicando muito pouca ou nenhuma validação sobre os identificadores extraídos do esquema (nomes de mensagens, tipos, etc.). Um esquema manipulado por um atacante pode inserir código malicioso nessa cadeia, de modo que quando a função sintética é finalmente avaliada, o código injetado é executado no contexto do processo que carrega o esquema.

Esse vetor converte um esquema malicioso em uma porta para acessar variáveis de ambiente, segredos, conexões a bases de dados e outros recursos internos; também permite movimentos laterais se a aplicação estiver implantada em infraestrutura compartilhada. Não é apenas um risco para servidores: se desenvolvedores carregam e decodificam esquemas não confiáveis em suas máquinas locais, também podem ficar comprometidos seus ambientes de trabalho.

O problema foi descoberto pelo pesquisador Cristian Staicu e documentado pela empresa de segurança Endor Labs em um relatório detalhado; a vulnerabilidade está registrada no GitHub como GHSA-xq3m-2v4x-88gg e Endor Labs explica o mecanismo e mostra um PoC em sua análise ( Relatório do Endor Labs). Embora os autores do relatório tenham assinalado que a exploração é simples, por agora, não foi confirmada atividade maliciosa estendida em ambientes de produção.

A vulnerabilidade afeta versões de protobuf.js anteriores ou iguais a 8.0.0 e 7.5.4. Os mantenedores publicaram correcções disponíveis nos principais ramos: a série 8.x foi corrigida com a versão 8.0.1 e a série 7.x com a 7.5.5; os pacotes npm com os adesivos foram publicados em abril (atualizações para 8.x e 7.x em diferentes datas). Você pode consultar o repositório e notas de segurança na página do projeto no GitHub: protobuf.js no GitHub e os seus releases.

A solução urgente que se aplicou no adesivo consiste em sanitizar os nomes de tipo, eliminando caracteres não alfanuméricos para impedir que um atacante feche a função sintética e adicione instruções maliciosas. No entanto, os especialistas apontam que uma correção mais robusta passa por deixar de usar completamente a geração dinâmica de código com Function () para processar identificadores que podem vir de fontes externas: evitar o “round-tripping” de identificadores através de código gerado é uma reparação de design mais segura e duradoura.

Se o seu projeto depende de protobuf.js, ele atua já: atualiza as versões patchadas, verifica o grafo de dependências em busca de versões vulneráveis (mesmo como dependências transitivas) e trata a carga de esquemas como entrada não confiável. Para equipamentos de produção, uma prática recomendada é empregar esquemas pré-compilados ou estáticos em vez de gerar e avaliar código em tempo de execução. Endor Labs também sugere auditar dependências transitivas e revisar pipelines de CI/CD que possam introduzir esquemas não verificados.

Em termos práticos, você pode verificar que versão está instalada com comandos do gestor de pacotes (por exemplo, inspecionando o package.json ou usando ferramentas como npm ls) e forçar atualizações às versões seguras (por exemplo, npm install protobufjs@ ^8.0.1 ou a versão 7.5.5 segundo o ramo que você usa). Além disso, é recomendável incorporar digitalizações automáticas de software na pipeline e políticas que evitem a descarga e execução de esquemas de origem não controlados.

A divulgação pública incluiu um PoC na própria assessoria de segurança do projeto, o que facilita equipamentos técnicos replicar o problema para validar o problema em ambientes controlados; a assessoria oficial no GitHub contém o link para esse exemplo e a discussão técnica ( Assessoria no GitHub). Se precisar de mais contexto sobre a descoberta e recomendações técnicas, a análise do Endor Labs está bem documentada e vale a pena lê-lo cuidadosamente: Relatório do Endor Labs.

A lição para a comunidade de desenvolvimento é dupla: por um lado, a grande conveniência de gerar código dinâmicamente traz riscos quando as entradas não estão bem validadas; por outro, a enorme dependência em bibliotecas compartilhadas faz com que uma única vulnerabilidade possa ter um alcance amplo. Actualizar, auditar e reduzir a superfície de exposição continua a ser a melhor defesa.