CVE-2023-4863

Overflow de heap (escrita fora dos limites) no decodificador lossless (VP8L) da libwebp, explorável com uma imagem WebP maliciosa embutida em página HTML. Afeta o Chrome antes de 116.0.5845.187 e qualquer software que embuta libwebp antes de 1.3.2 — o que é o ponto crítico, porque libwebp é vendorizada dentro de dezenas de frameworks (Electron, toolkits de imagem, outros navegadores), então corrigir só o Chrome não resolve o problema em outros produtos. Está no catálogo KEV da CISA porque foi explorada in-the-wild antes da correção, ligada à cadeia BLASTPASS usada para instalar spyware Pegasus via iMessage no iOS.

CWE-787 (out-of-bounds write). O bug está em ReadHuffmanCodes/BuildHuffmanTable, em src/dec/vp8l_dec.c e src/utils/huffman_utils.c da libwebp. O decodificador WebP lossless usa Huffman coding tanto para os pixels quanto, recursivamente, para as próprias tabelas de Huffman que descrevem a codificação. Antes da correção, o código calculava um tamanho de alocação para a tabela combinada de Huffman (huffman_tables) a partir de um tamanho pré-calculado fixo, e depois construía as cinco tabelas de código (uma para cada alfabeto — literais, distância, etc.) diretamente dentro dessa alocação, avançando um ponteiro (huffman_table += size).

O atacante controla integralmente os bytes do bitstream WebP: os code lengths de cada alfabeto, o número de meta-códigos Huffman e o uso ou não de cache de cores. Combinando esses parâmetros é possível fazer com que o tamanho real necessário para as cinco tabelas ultrapasse o tamanho pré-calculado que foi alocado, e a construção da tabela escreve além do buffer alocado no heap.

A correção (commit 902bc9190331343b2017211debcec8d2ab87e17a, liberada em libwebp 1.3.2) reestrutura o código para fazer duas passagens: primeiro calcula o tamanho total real necessário sem escrever nada, aloca um buffer maior se necessário, e só então constrói as tabelas. Também introduz uma estrutura HuffmanTables com gerenciamento de segmentos e alocação/desalocação dedicadas, eliminando o vínculo direto entre um tamanho pré-calculado estático e a escrita real.

O vetor é qualquer caminho de código que decodifique uma imagem WebP fornecida por um atacante através da libwebp — no caso do Chrome, isso significa simplesmente abrir uma página HTML com uma imagem WebP maliciosa embutida (UI:R do vetor CVSS reflete essa interação minima: carregar a página). Não é necessário autenticação nem configuração especial; qualquer processo que decodifique WebP não confiável está exposto, incluindo aplicações Electron e outras ferramentas que estaticamente vinculam versões antigas da libwebp.

A construção do payload não é trivial: segundo análise pública da Isosceles, é preciso manipular precisamente cinco segmentos distintos da tabela Huffman (cada um com alfabeto de tamanho diferente) para empurrar o ponteiro de escrita além do buffer alocado — exige entendimento fino do formato VP8L, mas existe PoC público de trigger.

A exploração confirmada in-the-wild está associada à cadeia BLASTPASS documentada pelo Citizen Lab: um exploit zero-click de iMessage no iOS explorava CVE-2023-41061 para rotear uma imagem para um processo sem sandbox, e a corrupção de memória nesse componente WebP (a mesma família de bug, relatada por Apple SEAR e Citizen Lab em 6/9/2023) permitia execução de código, usada para instalar spyware Pegasus da NSO Group. O próprio changelog do Chrome confirma: 'Google is aware that an exploit for CVE-2023-4863 exists in the wild.' O resultado final da exploração é corrupção de memória no processo de renderização/decodificação, ponto de partida para RCE quando encadeado com outras primitivas de escape de sandbox.

Atualizar o Chrome para 116.0.5845.187 (Windows: .187 ou .188) ou, para qualquer outro produto que embuta a biblioteca, atualizar a libwebp para 1.3.2 ou superior. Isso é crítico: como a libwebp é frequentemente vendorizada/estaticamente linkada por outros projetos (frameworks baseados em Electron, bibliotecas de processamento de imagem, outros navegadores e leitores de imagem), atualizar o Chrome não corrige aplicações de terceiros que carregam sua própria cópia da libwebp — cada dependente precisa recompilar/republicar com a versão corrigida.

Não existe flag de configuração, regra de WAF ou controle de rede que mitigue esse bug de forma confiável, porque a falha ocorre na decodificação local do arquivo de imagem, não em uma requisição HTTP inspecionável de forma útil. O único paliativo real na ausência de atualização é impedir a renderização/decodificação de WebP não confiável (desabilitar suporte a WebP na aplicação, se ela oferecer essa opção), o que tem custo funcional alto e não é viável na maioria dos navegadores.

Não há assinatura de rede confiável para detectar exploração, já que o payload é apenas um arquivo de imagem WebP malformado transportado normalmente sobre HTTPS. O sinal mais útil é o de crash/telemetria: relatórios de falha do processo de renderização ou de decodificação de imagem apontando para BuildHuffmanTable ou vp8l_dec.c (via AddressSanitizer, monitoramento de crash de EDR, ou logs de crash do próprio navegador) indicam tentativa de exploração ou payload malformado. Sem instrumentação de crash dedicada, a exploração é praticamente invisível em logs convencionais.