CVE-2016-0189
Corrija agora. Ela está sob exploração confirmada pelo CISA e tem exploit funcional público.
Apply updates per vendor instructions.
Resumo
Falha de corrupção de memória nas engines de script VBScript (5.7/5.8) e JScript 5.8 da Microsoft, usadas pelo Internet Explorer 9 a 11 e por outros componentes do Windows que hospedam essas engines. Permite execução remota de código com os privilégios do usuário atual via página web maliciosa; foi explorada ativamente antes da correção e está no catálogo KEV da CISA, o que justifica a urgência mesmo sendo uma falha de 2016 em software majoritariamente fora de suporte hoje.
Detalhamento técnico
A vulnerabilidade (CWE-119, violação de limites de buffer/memória) está no manuseio de objetos em memória pelas engines VBScript e JScript — os componentes jscript.dll e vbscript.dll do Windows, carregados pelo mshtml.dll quando o Internet Explorer (ou qualquer processo que hospede o Trident/MSHTML) interpreta script embutido numa página HTML. A Microsoft descreveu o problema genericamente como erro no tratamento de objetos, sem detalhar a primitiva exata; é uma CVE distinta de CVE-2016-0187, corrigida no mesmo boletim, mas com mecanismo de corrupção diferente.
O PoC público (Theori, github.com/theori-io/cve-2016-0189) e a análise da Virus Bulletin situam o bug em manipulação de arrays/objetos VBScript que gera uma condição de type confusion ou uso indevido de referência, dando ao atacante controle sobre estruturas internas da engine. A técnica de exploração documentada reconstrói o chamado "God Mode" — um estado interno da VBScript engine que remove as restrições normais de sandbox do script, técnica historicamente associada a exploits anteriores como CVE-2014-6332. Isso evita a necessidade de heap-spray e ROP chain tradicionais: uma vez alcançado o estado privilegiado, o atacante executa comandos arbitrários (ex.: chamadas a objetos COM/ActiveX perigosos) diretamente pelo script.
O atacante controla o conteúdo da página HTML/VBScript servida à vítima; não controla nada do lado do sistema alvo além do que o navegador expõe ao script. AC:H no vetor CVSS reflete que reproduzir a corrupção de memória de forma confiável exige manipulação cuidadosa de estado (o próprio PoC do Theori nota que "não é 100% confiável").
Como é explorada
O vetor é web: a vítima precisa abrir, no Internet Explorer (ou em qualquer aplicação que renderize HTML via MSHTML, incluindo determinados documentos Office que habilitam script), uma página ou documento controlado pelo atacante. Não exige autenticação nem configuração fora do padrão — só que o VBScript/JScript esteja habilitado, o que era o padrão em todas as zonas de segurança do IE na época. UI:R no vetor CVSS corresponde exatamente a essa exigência de interação (clicar em link, abrir e-mail com preview HTML, etc.).
A CISA confirma exploração ativa (entrada no KEV, adicionada em 2022 com prazo de correção retroativo), consistente com relatos da época de que a falha foi usada como zero-day antes da correção de maio/2016 e depois incorporada a kits de exploração automatizados que visavam usuários de IE desatualizados. O PoC público do Theori (EDB-40118) demonstra o bypass de sandbox e execução de código em IE11/Windows 10, mas não é um exploit determinístico — os próprios autores relatam necessidade de retry.
O resultado final da exploração bem-sucedida é execução de código arbitrário com os privilégios do usuário que executa o IE; se esse usuário tiver direitos administrativos, o atacante obtém controle total do sistema (instalar programas, alterar/apagar dados, criar contas).
Versões
Como se proteger
A correção definitiva é aplicar as atualizações da Microsoft: MS16-051 (KB3155533 e equivalentes por sistema — 3154070, 3156387, 3156421) para ambientes com Internet Explorer 8 ou superior instalado, ou MS16-053 (KB3156764, com variantes 3158991 e 3155413) para sistemas sem IE instalado ou com IE 7 ou anterior. Ambos os boletins substituem atualizações anteriores da série MS16-003/MS16-037 (KBs 3124624, 3124625, 3148198, 3147461, 3147458).
Se a atualização não puder ser aplicada, o paliativo real é desabilitar o VBScript e/ou o Active Scripting nas zonas de segurança do Internet Explorer (Internet e Intranet), o que quebra funcionalidade de sites que dependam de script legado. Restringir o uso do IE como navegador padrão e migrar para um navegador com engine de renderização atualizada reduz a superfície, mas não é uma correção da CVE em si — é redução de exposição.
Não funciona como mitigação: EMET ou outras ferramentas de proteção de exploração genéricas ajudavam a dificultar algumas cadeias de exploração da época, mas não corrigiam a falha nem bloqueavam de forma confiável a técnica de bypass de sandbox documentada ("God Mode"), que opera dentro do próprio interpretador de script e não depende necessariamente de técnicas de memória detectáveis por mitigação genérica de exploit.
Como detectar
Não há assinatura de log confiável e específica para esta CVE em ambientes corporativos típicos — a exploração ocorre inteiramente no processo do navegador/renderizador via script malicioso embutido em HTML, sem artefato de rede distintivo além do próprio conteúdo da página. Sinais indiretos a procurar: proxies/IDS com regras para exploit kits ativos em 2016 que incorporaram esta CVE, crashes ou anomalias do processo iexplore.exe/jscript.dll/vbscript.dll em EDR, e telemetria de acesso a domínios associados a campanhas de exploração conhecidas da época — nenhum desses é um indicador definitivo isolado.