CVE-2023-5217

Falha de heap buffer overflow no codificador VP8 da libvpx, explorável a partir de uma página HTML maliciosa no Chrome (e em qualquer software que use libvpx para codificar VP8, como navegadores baseados em Chromium, clientes WebRTC e pipelines de vídeo). Está no catálogo KEV da CISA como exploração confirmada e tem PoC pública, o que eleva a urgência de patch apesar do vetor exigir interação do usuário.

O problema está em vp8_change_config(), em vp8/encoder/onyx_if.c. A libvpx aloca as estruturas de multi-threading do encoder VP8 uma única vez, dentro de vp8_create_compressor(), com base na contagem de threads (g_threads) e na resolução vigentes no momento da criação do encoder. O problema é que a API pública (vpx_codec_enc_config_set) permite alterar a contagem de threads e a resolução depois que o encoder já foi criado, sem que essas alocações sejam refeitas — gerando um descompasso entre o tamanho dos buffers alocados e o que o código de codificação multithread escreve neles.

O resultado é um heap buffer overflow (CWE-122 / write out-of-bounds, CWE-787) quando uma sequência de reconfiguração (mudança de resolução seguida de mudança de contagem de threads, ou vice-versa) é executada em um encoder VP8 já inicializado em modo multithread. O atacante controla os parâmetros de configuração do encoder — resolução e número de threads — via chamadas de API expostas ao conteúdo web (WebRTC / WebCodecs), não diretamente memória ou ponteiros.

O fix aplicado (commit 3fbd1dca) não corrige a lógica de realocação; ele restringe o comportamento: vp8_change_config() passa a preservar o valor original de multi_threaded vindo de cpi->oxcf em reconfigurações subsequentes, efetivamente impedindo que a contagem de threads seja alterada após a criação do encoder VP8. É uma correção de superfície de ataque, não uma reescrita do gerenciamento de buffers — o teste de regressão adicionado (encode_api_test.cc) documenta isso explicitamente com um TODO pedindo a correção completa do VP8 futuramente (o mesmo teste foi corrigido de forma completa apenas para VP9).

O vetor é uma página HTML/JS maliciosa que aciona o pipeline de codificação VP8 da libvpx dentro do navegador — via WebRTC (RTCPeerConnection com renegociação de resolução/threads durante uma sessão de vídeo) ou via WebCodecs VideoEncoder configurado para VP8. O atacante precisa induzir a vítima a abrir a página (UI:R no vetor CVSS) e a sequência de codificação a executar mudanças de configuração (resolução e contagem de threads) que disparam o descompasso de alocação. Não é necessária autenticação nem configuração não padrão do navegador — o requisito real é que o encoder VP8 multithread da libvpx seja acessível a partir de conteúdo web, o que é o caso padrão em navegadores modernos.

A presença no catálogo KEV da CISA confirma exploração ativa antes da correção. A cobertura da época (ligada ao lote de zero-days em bibliotecas de imagem/vídeo de setembro-outubro de 2023, incluindo a falha relacionada em libwebp) tratou esse conjunto de vulnerabilidades como usado por atores sofisticados contra alvos específicos, não como exploração massiva e indiscriminada — mas a fonte primária aqui apenas confirma exploração via KEV, sem detalhar campanha específica.

O impacto final, segundo o CVSS (C:H/I:H/A:H), é potencial execução de código no processo renderer/GPU que hospeda o codificador, ou ao menos corrupção de heap explorável para além de um crash simples — consistente com heap overflow em código nativo de mídia, historicamente usado como primitiva para escape de sandbox quando encadeado com outras falhas.

A correção definitiva é atualizar. Google Chrome para 117.0.5938.132 ou superior; qualquer software que embuta libvpx diretamente (outros navegadores baseados em Chromium, Firefox, servidores de mídia, stacks WebRTC, builds de ffmpeg com libvpx) deve atualizar a biblioteca para 1.13.1 ou superior, que incorpora o mesmo commit de correção.

Não há flag de configuração exposta ao usuário final que mitigue o problema sem atualizar — a própria correção do fornecedor consiste em bloquear internamente a troca de contagem de threads após a criação do encoder VP8, comportamento que não é controlável externamente em versões vulneráveis. Como paliativo real, apenas restringir ou desabilitar o acesso de páginas web ao WebRTC/WebCodecs com codificação VP8 (ex.: políticas de enterprise que bloqueiam captura de mídia e RTCPeerConnection) reduz a superfície, ao custo de quebrar videoconferência e afins — não é uma mitigação recomendada como solução, apenas um controle compensatório temporário até o patch.

Não funciona como mitigação: desabilitar aceleração de hardware de vídeo, isso não afeta o encoder de software VP8 da libvpx; tampouco ajustar manualmente configurações de qualidade de vídeo em conferências, pois o atacante controla a sequência de reconfiguração via script, não a vítima.

Não há assinatura de rede confiável: a exploração ocorre inteiramente no lado do cliente, dentro do processo de codificação de vídeo do navegador, sem tráfego distintivo. O sinal mais direto é o comportamento de crash — relatórios de crash do Chrome (chrome://crashes ou telemetria corporativa) apontando para falhas dentro de vp8/encoder/onyx_if.c ou em rotinas de multithreading do encoder VP8 da libvpx, especialmente em processos associados a sessões WebRTC ou uso de WebCodecs com VP8.

Em ambientes que rodam builds instrumentados com ASan/heap sanitizers (uso interno de QA, não produção), o padrão esperado é um heap-buffer-overflow write disparado após sequência de vpx_codec_enc_config_set com mudança de resolução e contagem de threads. Em produção, a ausência de crashes reproduzíveis não garante ausência de exploração, já que heap corruption pode ser silenciosa ou controlada pelo atacante para evitar crash imediato.