CVE-2022-2294

Heap buffer overflow no componente WebRTC do Chrome (e no LibWebRTC usado por WebKitGTK/WPE WebKit quando compilado com a opção USE_LIBWEBRTC), acionado por uma página HTML maliciosa. É a vulnerabilidade que importa: Google confirmou exploit em uso ativo no momento da publicação e está no catálogo KEV da CISA. CVSS 8.8 é coerente aqui — não é um caso de nota inflada, pois exploração real já existia antes do patch.

A falha é um heap buffer overflow (CWE-122) dentro da stack WebRTC do Chromium/Blink — o mesmo código-base usado como LibWebRTC em outros navegadores. Buffer overflows em WebRTC costumam ocorrer no processamento de pacotes de mídia ou de sinalização (parsing de RTP/RTCP, decodificação de codecs, ou manipulação de buffers de jitter), onde o tamanho de dados recebidos da rede ou fornecidos via JavaScript/HTML não é validado corretamente contra o tamanho alocado do buffer, permitindo escrita fora dos limites na heap. O bug foi catalogado internamente como crbug.com/1341043 e reportado por Jan Vojtesek, da Avast Threat Intelligence, em 1º de julho de 2022 — pouco menos de duas semanas antes da correção.

O atacante controla o conteúdo de uma página HTML que, ao ser carregada, invoca APIs de WebRTC (por exemplo, via JavaScript que inicia uma sessão de mídia ou processa dados relacionados). Isso é suficiente para acionar o caminho de código vulnerável sem exigir qualquer permissão elevada, plugin ou configuração fora do padrão no lado do Chrome — WebRTC vem habilitado por padrão no Chrome.

Uma nuance importante para quem roda WebKitGTK ou WPE WebKit (base usada em navegadores embarcados e alguns ambientes Linux/GNOME): o mesmo código LibWebRTC introduz a mesma falha nesses motores, mas apenas se o binário foi compilado com a flag CMake USE_LIBWEBRTC habilitada e construído a partir do repositório fonte — não das tarballs oficiais, que não incluem LibWebRTC e têm o suporte desabilitado por padrão. Isso restringe bastante o universo de instalações afetadas fora do Chrome propriamente dito.

O vetor é o clássico do Chrome: visitar uma página HTML maliciosa (ou anúncio malicioso embutido em página legítima, iframe, etc.) enquanto o navegador processa conteúdo relacionado a WebRTC. Não há necessidade de autenticação, interação complexa do usuário além de abrir/visitar a página, nem configuração não padrão — CVSS reflete isso corretamente com AC:L e UI:R (alguma interação do usuário, como abrir o link, é necessária, mas nada além disso).

Google declarou explicitamente no advisory de release que 'está ciente de que existe um exploit para CVE-2022-2294 in the wild' — ou seja, havia exploração ativa documentada pelo próprio fornecedor antes da correção pública, o que justificou a entrada no catálogo KEV da CISA. Não há detalhes técnicos públicos sobre a cadeia completa de exploração (o bug tracker interno do Chromium, crbug.com/1341043, permanece restrito), então não se sabe publicamente se essa CVE foi usada isoladamente ou como parte de uma cadeia com outra falha para escapar do sandbox do renderer.

O resultado de uma exploração bem-sucedida é corrupção de heap controlada dentro do processo que processa WebRTC (renderer, no modelo multi-processo do Chrome), que pode levar a execução de código arbitrário dentro daquele processo — daí o Impact C:H/I:H/A:H no CVSS. Para atingir execução de código fora do sandbox do renderer, normalmente seria necessária uma segunda falha de escape de sandbox, que não está documentada nesta CVE.

Atualizar o Chrome para a versão 103.0.5060.114 ou posterior resolve a falha; a atualização do canal estável ocorreu em 4 de julho de 2022 (Windows) com propagação nos dias seguintes para outras plataformas. Distribuições Linux publicaram pacotes chromium equivalentes na mesma janela — Fedora 35 e 36 lançaram 103.0.5060.114-1 em 27–28 de julho de 2022; Gentoo e outras distros seguiram com seus próprios advisories (GLSA 202208-35, 202208-39, 202311-11).

Para WebKitGTK e WPE WebKit, a correção está nas versões 2.36.5 e posteriores, mas só é relevante para builds compilados a partir do código-fonte com a flag CMake USE_LIBWEBRTC habilitada — as tarballs oficiais não são afetadas porque não incluem LibWebRTC e o suporte vem desabilitado por padrão. Se você mantém um build customizado com essa flag ativa, atualizar para 2.36.5+ é obrigatório; caso contrário, não há exposição por essa via.

Não existe paliativo de configuração conhecido e documentado que neutralize o bug sem atualizar o binário — desabilitar WebRTC completamente (via política empresarial, se aplicável no ambiente) reduziria a superfície de ataque, mas isso quebra funcionalidade legítima de chamadas de voz/vídeo em várias aplicações web e não é uma mitigação oficial do fornecedor, apenas um controle compensatório de última instância enquanto a atualização não é aplicada.

Não há assinatura de rede ou padrão de log confiável documentado publicamente para detectar tentativas de exploração desta falha — o exploit in-the-wild mencionado pelo Google nunca teve detalhes técnicos divulgados (o bug tracker crbug.com/1341043 permanece restrito), e não há IOCs (indicadores de comprometimento) publicados associados à campanha original. Em ambientes corporativos, o sinal prático mais viável é monitorar crashes ou encerramentos anômalos do processo renderer do Chrome associados a atividade WebRTC, e correlacionar com telemetria EDR de execução de código anômala pós-carregamento de página — mas isso é genérico para exploração de heap overflow em navegador, não específico desta CVE.