CVE-2018-6065

Integer overflow no V8 (motor JavaScript do Chromium) ao calcular o tamanho de alocação necessário para instanciar um novo objeto JavaScript. Uma página HTML maliciosa pode forçar esse cálculo a estourar, resultando em heap corruption dentro do processo de renderização. A falha está no catálogo KEV da CISA com exploração confirmada e afeta não só o Chrome, mas qualquer navegador baseado em Chromium que não tenha atualizado o V8, incluindo forks como o Xiaomi Mi6 Browser.

O bug (CWE-190, integer overflow, levando a CWE-787, out-of-bounds write) está no código do V8 responsável por calcular o tamanho de alocação de heap ao instanciar um objeto JavaScript. Quando o atacante controla a estrutura do objeto (número/tipo de propriedades, arrays, ou construções que influenciam o cálculo de tamanho), é possível fazer a aritmética de tamanho estourar o limite do inteiro usado internamente, resultando em uma alocação menor do que o necessário. Escritas subsequentes nesse buffer subalocado corrompem o heap adjacente.

O advisory do ZDI (referente à mesma classe de bug em um fork Chromium, o Xiaomi Mi6 Browser, identificado independentemente via Pwn2Own) aponta a função CalculateInstanceSizeHelper como o ponto específico onde a falta de validação de dados controlados pelo atacante permite o overflow antes da alocação do buffer. A CVE-2018-6065 foi originalmente reportada a Google por Mark Brand, do Google Project Zero (bug interno 808192), e corrigida no Chrome 65.

Como é um bug na engine de execução JavaScript, e não em uma API específica do DOM ou extensão, ele afeta qualquer produto que embarque a versão vulnerável do V8 — não apenas o Chrome. O CISA KEV cita explicitamente que a falha 'pode afetar múltiplos navegadores baseados em Chromium, incluindo mas não limitado a Google Chrome, Microsoft Edge e Opera'.

O vetor é uma página HTML/JavaScript maliciosa (drive-by): a vítima precisa visitar a página (UI:R no vetor CVSS), sem necessidade de autenticação ou privilégios especiais no navegador. O atacante manipula construções JavaScript que disparam o cálculo de tamanho de alocação de objeto de forma a causar o overflow, obtendo uma alocação de heap menor que o necessário; escritas subsequentes no objeto corrompem memória adjacente no heap do processo de renderização.

Explorar heap corruption em V8 para execução de código normalmente exige encadear a corrupção de memória com técnicas de manipulação de heap (grooming) para transformar a escrita fora de limites em controle de fluxo de execução — isso é o que dá complexidade prática ao ataque, mesmo com AC:L no vetor formal. Em cenários como o Pwn2Own (de onde saiu o advisory do ZDI para o fork Xiaomi), esse tipo de bug em V8 é tipicamente combinado com uma falha de escape de sandbox para obter execução de código completa no sistema; sozinho, dentro do processo renderer sandboxed do Chrome, o impacto prático pode ficar limitado ao sandbox.

A presença no catálogo KEV da CISA confirma exploração ativa documentada, mas sem atribuição pública a campanha específica nem indicação de uso em ransomware. Existe PoC pública referenciada (Exploit-DB), o que reduz a barreira para replicação da prova de conceito, embora weaponização completa (bypass de sandbox, payload final) siga exigindo trabalho adicional.

A correção definitiva é atualizar o Google Chrome para a versão 65.0.3325.146 ou posterior — a atualização é feita automaticamente pelo próprio navegador na maioria dos casos, mas ambientes gerenciados (imagens corporativas, appliances embarcando Chromium) precisam confirmar que a atualização foi de fato aplicada. Distribuições Linux que empacotam o Chromium separadamente (ex.: RHEL 6 Supplementary via RHSA-2018:0484, Debian via DSA-4182) publicaram pacotes próprios atualizados para 65.0.3325.146; sistemas nesses repositórios precisam do update do pacote, não apenas do binário do navegador.

Para forks e produtos baseados em Chromium que empacotam versões antigas do V8 — caso do Xiaomi Mi6 Browser, corrigido apenas na versionName 10.4.0 (versionCode 20181211), quase um ano depois do fix upstream — a exposição persiste até o fornecedor específico do fork atualizar seu motor. Não há flag de configuração ou controle no navegador que mitigue esse tipo de bug de motor JS sem desabilitar JavaScript inteiramente, o que quebra a usabilidade da maioria dos sites e não é uma mitigação prática recomendável. WAF ou controles de rede não têm efeito, pois o bug é client-side, disparado por conteúdo JavaScript processado localmente no navegador da vítima.

Não existe mitigação parcial confiável equivalente a 'patch virtual' para esse tipo de falha de engine — a única ação real é rastrear e atualizar todo software (navegadores, WebViews embutidos, browsers OEM) que embarque V8/Chromium vulnerável.

Não há assinatura de rede confiável para detectar tentativas de exploração, já que o ataque ocorre inteiramente client-side via JavaScript executado no processo de renderização do navegador — não há payload de rede distintivo além do carregamento da página maliciosa em si. Sinais indiretos possíveis incluem crashes repetidos do processo renderer do Chrome com padrões de corrupção de heap em relatórios de crash (se telemetria de crash estiver habilitada), ou, em cenários de exploração completa com escape de sandbox, atividade pós-exploração detectável por EDR no processo do navegador (criação de processos filhos inesperados, injeção de código).