CVE-2019-13720

Use-after-free no componente WebAudio do Google Chrome (CWE-416), explorável por uma página HTML maliciosa para corromper heap e potencialmente executar código no processo renderer. Foi descoberta pela Kaspersky enquanto investigava exploração ativa in the wild — o próprio Google confirmou no advisory que um exploit para essa falha já circulava antes da correção. Por isso está no catálogo KEV da CISA e tem CVSS 8.8, mas a exploração exige que a vítima visite uma página controlada pelo atacante (UI:R) — não é execução remota sem interação.

A falha reside na implementação da WebAudio API do Chromium (motor Blink). Um objeto associado ao grafo de processamento de áudio é liberado (freed) em um caminho de código, mas uma referência a esse objeto permanece acessível e é usada posteriormente — o padrão clássico de use-after-free (CWE-416). Isso normalmente ocorre quando callbacks assíncronos de áudio (como os disparados por nós do grafo WebAudio, alterações de estado do contexto de áudio, ou destruição de buffers) não são sincronizados corretamente com o ciclo de vida do objeto que os originou.

O atacante controla o conteúdo da página HTML/JavaScript que aciona a API WebAudio, incluindo a sequência de operações que leva à liberação prematura do objeto e ao timing da reutilização subsequente. Esse controle sobre timing e sobre o que é realocado no espaço de memória liberado é o que permite, em exploits maduros, transformar a corrupção de heap em execução de código controlado dentro do processo renderer (sandbox do Chrome).

O Google não publicou detalhes de código da correção (bug 1019226 permanece restrito), e não há CWE ou linha específica documentada publicamente pelo fornecedor além da classificação genérica "Use-after-free in audio". A vulnerabilidade também afeta o Qt WebEngine, que embarca o motor Chromium/Blink — a distribuição Gentoo classificou o mesmo bug como residente no "componente de áudio" do WebEngine, corroborando que o problema está na camada de mídia/áudio do Blink, não em código específico do Chrome per se.

O vetor é uma página HTML crafted que a vítima precisa abrir — não há execução sem interação do usuário. Não exige autenticação, acesso à rede interna nem configuração não padrão: o navegador vulnerável, no estado padrão, já expõe a API WebAudio a qualquer página web. Isso torna o requisito de exploração baixo em complexidade técnica para o atacante entregar o payload (basta convencer a vítima a acessar um link), mas alto em sofisticação para a construção do exploit em si (manipulação confiável de heap).

O Google confirmou no próprio advisory de lançamento do Chrome 78.0.3904.87 que havia relatos de um exploit para essa CVE em uso real antes da correção — reportado por pesquisadores da Kaspersky Labs (Anton Ivanov e Alexey Kulaev). Isso motivou a inclusão no catálogo KEV da CISA. Existe PoC pública documentada (referenciada via Packetstorm como "Google Chrome 78.0.3904.70 Remote Code Execution"), o que reduz a barreira para replicação por outros atores após a divulgação.

O resultado final da exploração bem-sucedida é execução de código arbitrário dentro do processo renderer do Chrome, com os privilégios desse processo — tipicamente ainda contido pela sandbox do navegador, exigindo uma cadeia adicional (sandbox escape) para comprometimento total do sistema. A CVE isolada não implica automaticamente controle total da máquina da vítima.

A correção definitiva é atualizar o Google Chrome para a versão 78.0.3904.87 ou superior nas plataformas Windows, Mac e Linux. Para produtos que embarcam o motor via Qt WebEngine, a versão corrigida é 5.14.1 ou superior — versões anteriores a 5.14.1 permanecem vulneráveis mesmo que o Chrome standalone da máquina já esteja atualizado, porque o WebEngine embute seu próprio Chromium.

Não há workaround de configuração documentado pelo fornecedor nem pela Gentoo ("There is no known workaround at this time"). Desativar JavaScript ou a WebAudio API reduziria a superfície de ataque, mas quebra funcionalidade da maioria dos sites e não é uma mitigação prática recomendada — trate como paliativo de última instância, não como controle real.

Como a exploração já foi observada in the wild antes do patch, tratar essa CVE como prioridade de atualização imediata é justificado independentemente de exposição percebida — qualquer sistema com Chrome ou aplicação baseada em Qt WebEngine desatualizado é candidato a comprometimento via navegação simples.

Não há assinatura de rede confiável para detectar tentativas de exploração desse use-after-free — o ataque ocorre inteiramente client-side, dentro do processamento de JavaScript/WebAudio da página, sem padrão de tráfego distintivo. Sinais indiretos possíveis incluem crashes ou encerramentos anômalos do processo renderer do Chrome (visíveis em logs de crash reporting corporativo) e telemetria de EDR que capture comportamento pós-exploração dentro do processo do navegador, já que a corrupção de heap em si não deixa rastro de rede.

Como existe PoC pública, ambientes que monitoram execução de exploits conhecidos (via assinatura de arquivo ou hash de página maliciosa) podem detectar reuso direto da PoC divulgada, mas variantes modificadas do exploit não seriam capturadas por esse método.