CVE-2016-1646

Falha de leitura fora dos limites (out-of-bounds read) no motor JavaScript V8 do Google Chrome, especificamente na implementação de Array.prototype.concat em builtins.cc. Afeta qualquer usuário do Chrome antes da versão 49.0.2623.108 que visite uma página com JavaScript malicioso; está no catálogo KEV da CISA, ou seja, há confirmação de exploração real, o que justifica o CVSS alto mesmo sendo 'apenas' uma leitura fora de limites.

O bug mora no fast-path de Array.prototype.concat dentro de builtins.cc do V8. Esse caminho rápido assume que os elementos do array (no receiver ou na cadeia de protótipos) são 'simples' — valores primitivos armazenados diretamente no backing store (FixedArray) — e evita as checagens mais custosas do caminho lento. O problema é que a checagem de 'array simples' não cobre corretamente todos os casos: se o receiver ou algo na prototype chain expõe elementos complexos (por exemplo, via acessores/getters), o motor invoca esses getters durante a concatenação.

Invocar um getter arbitrário durante a operação pode disparar efeitos colaterais, entre eles uma coleta de lixo (GC). O GC pode fazer 'right-trim' do backing store — encurtá-lo removendo slots não usados no final — enquanto o código de concat ainda mantém um índice ou tamanho calculado antes do trim. O acesso subsequente via FixedArray::get não revalida esse limite, e a leitura cai fora da região realocada, expondo memória crua do heap do V8 ao script JavaScript.

O CWE aplicável é out-of-bounds read (CWE-125), decorrente de um problema de gerenciamento de tempo de vida/tamanho de buffer (uso de dado obsoleto após GC — correlato a CWE-416/CWE-704, já que a causa raiz é tratar tipos de elemento incorretamente após um evento assíncrono ao fluxo principal). O atacante controla o conteúdo do array, a presença de getters na cadeia de protótipos e, indiretamente, o momento do GC ao dimensionar as alocações — mas não controla precisamente qual endereço de memória será lido, o que limita (mas não elimina) a utilidade da falha como primitiva de exploração.

O vetor é 100% client-side: o atacante precisa que a vítima abra uma página (ou anúncio, iframe, e-mail HTML renderizado pelo Chrome) contendo JavaScript malicioso que chama Array.prototype.concat sobre uma estrutura de dados especialmente montada (array com elementos providos por acessores/getters, possivelmente via Object.defineProperty ou Proxy, posicionado no receiver ou na prototype chain). Não há necessidade de autenticação nem de configuração não padrão no navegador — é o cenário padrão de 'visitar um link'. A interação do usuário exigida (UI:R no vetor CVSS) é justamente essa navegação.

Sozinha, a falha causa negação de serviço (crash por acesso inválido) ou vaza bytes de memória do heap do V8 para o script atacante. Esse vazamento é valioso como primitiva de info-leak em cadeias de exploração maiores: permite inferir endereços/ponteiros do heap, útil para contornar ASLR e viabilizar RCE quando combinado com outra vulnerabilidade de corrupção de memória (o próprio boletim de março de 2016 do Chrome corrige, no mesmo pacote, use-after-free em Navigation e Extensions e um buffer overflow em libANGLE reportado via Pwn2Own — indicando o tipo de vizinhança de bugs explorados em conjunto na época).

A presença no catálogo KEV da CISA confirma exploração observada in-the-wild, mas as fontes consultadas não detalham qual campanha ou grupo a utilizou nem se foi explorada isoladamente ou como parte de uma cadeia com outros CVEs do mesmo lote (1647–1650).

Atualizar o Google Chrome para a versão 49.0.2623.108 ou posterior elimina a falha — essa é a correção oficial do fornecedor, aplicada também ao branch V8 4.9 (tip do 4.9.385.33). O commit de correção (codereview.chromium.org/1804963002) reescreveu a lógica de detecção de 'elementos simples' em builtins.cc e adicionou tratamento em elements.cc para não confiar em acessos diretos ao FixedArray após possíveis GCs disparados por getters.

Para distribuições Linux que empacotam Chromium separadamente: Red Hat Enterprise Linux 6 (Server, Workstation, Desktop e variantes EUS 6.7) corrige via RHSA-2016:0525, atualizando o pacote chromium-browser para 49.0.2623.108. Gentoo recomenda atualizar www-client/chromium para >= 50.0.2661.102 (release cumulativa que inclui esta e outras correções); o próprio GLSA 201605-02 declara explicitamente que não há workaround conhecido.

Não há mitigação de configuração real (flag, política de grupo) documentada nas fontes consultadas — a única forma de neutralizar completamente o vetor sem atualizar seria desabilitar a execução de JavaScript no navegador, o que quebra a usabilidade da maioria dos sites e não deve ser tratado como solução, apenas como paliativo extremo em ambientes de altíssimo risco sem possibilidade de patch imediato.

Não há assinatura de rede ou log de servidor confiável para detectar exploração, pois o bug é executado inteiramente dentro do processo renderer/V8 no lado do cliente — o tráfego é apenas JavaScript comum servido por uma página, indistinguível de conteúdo legítimo sem análise estática/dinâmica do script. Sinais indiretos incluem relatórios de crash do Chrome (crash reports com stack trace apontando para builtins.cc/Array.prototype.concat ou para rotinas de elements.cc do V8) e, em ambientes com sandboxing/EDR que inspecionam JavaScript antes da execução, heurísticas que identifiquem manipulação anômala de arrays com getters combinada com chamadas a concat — mas nenhuma das fontes consultadas descreve um indicador de comprometimento específico ou publicado para esta CVE.