CVE-2018-8174

Falha de use-after-free no motor VBScript do Windows, explorável para execução remota de código quando a vítima abre um documento Office ou visualiza uma página/arquivo HTA que aciona o VBScript engine — mesmo em sistemas onde o Internet Explorer não é o navegador padrão, porque o Office e o Windows chamam o componente OLE/mshtml/vbscript.dll independentemente disso. Foi explorada como 0-day antes da correção (detectada por Kaspersky e Qihoo 360) e está no catálogo KEV da CISA, o que confirma exploração ativa; o CVSS 7.5 com AC:H reflete que a exploração exige engenharia — a vítima precisa abrir um arquivo malicioso — mas o impacto final é RCE completo com os privilégios do usuário.

A vulnerabilidade (CWE-787/UAF, listada pela CISA como out-of-bounds write) está na forma como o VBScriptClass::Release trata objetos que implementam o evento não-documentado Class_Terminate. Quando um array contendo um objeto é apagado com Erase, o VBScript decrementa a contagem de referências e, se ela chega a zero, chama Class_Terminate — mas esse método pode, dentro de si, criar uma nova referência ao próprio objeto que está sendo destruído (ex.: atribuindo-o a outra variável). VBScriptClass::Release não reavalia a contagem de referências após a execução de Class_Terminate, então o objeto é destruído mesmo com uma referência 'viva' pendente em outra variável — essa variável passa a apontar para memória heap já liberada (dangling pointer).

A partir do dangling pointer, um atacante controla o conteúdo realocado naquele bloco de heap e consegue forjar uma estrutura VARIANT arbitrária, o que dá controle sobre tipo e ponteiro de dados — base clássica para leitura/escrita arbitrária e, em seguida, execução de shellcode. O PoC público (exploit-db 44741) demonstra a cadeia completa em uma página HTML/VBScript carregada pelo Internet Explorer 11 em Windows 7: usa a UAF para vazar endereços de módulos, resolve GetProcAddress manualmente via PE, localiza ntdll/kernel32 e chama VirtualProtect para tornar shellcode executável, contornando Control Flow Guard via manipulação de contexto de NtContinue.

O vetor real de exploração relatado por Kaspersky e Qihoo 360 (referenciado no blog da 0patch) foi um documento Office com objeto OLE embutido que aponta para um recurso remoto carregado pelo motor do IE, técnica que dispensa o IE como navegador padrão. Pré-requisito real é interação do usuário (abrir o arquivo/documento) — não há exploração sem clique — mas não exige autenticação nem configuração incomum: o VBScript engine estava habilitado por padrão em todas as versões de Windows listadas na época.

A correção oficial veio no Patch Tuesday de maio de 2018 (atualização cumulativa da respectiva versão de Windows); aplicar essa atualização é a mitigação correta e suficiente segundo o MSRC. Não há workaround de configuração documentado nas fontes consultadas além do patch oficial — a suposta alternativa de 'desregistrar vbscript.dll' não está confirmada nas fontes aqui usadas e não deve ser tratada como equivalente ao patch sem validação própria do ambiente.

Vale notar que a atualização de maio de 2018 quebrou rede/conectividade em alguns sistemas Windows 7/Server 2008, levando administradores a evitar aplicá-la; a 0patch lançou um micropatch de terceiros (não oficial) para oleaut32.dll que reproduz a correção da Microsoft com uma única instrução (mov word [rbx], 0, zerando o campo vt do VARIANT) para quem não conseguia aplicar o KB oficial — isso é um controle compensatório de terceiro, não substitui o patch da Microsoft e deve ser avaliado com cautela por não vir do fornecedor.

Em nível de rede/endpoint, procure documentos Office (RTF/DOC/DOCX) com objetos OLE embutidos que referenciam recursos HTA ou scriptlets remotos — esse foi o vetor observado nas campanhas detectadas por Kaspersky e Qihoo 360 antes da correção. Em logs do Internet Explorer/wscript, crashes do processo wscript.exe ou iexplore.exe dentro de oleaut32.dll (função VariantClear) no momento do processamento de um script VBScript são indício de tentativa de exploração ou de execução do PoC. Não há assinatura de rede genérica confiável, já que o payload varia por campanha; a detecção mais eficaz continua sendo comportamental (carregamento inesperado do motor VBScript por processos Office) e a verificação de patch nos hosts.