CVE-2014-6332

Falha de corrupção de memória na biblioteca OleAut32.dll do Windows, na função responsável por redimensionar objetos SAFEARRAY (usada por OLE Automation e VBScript). Um site malicioso aberto no Internet Explorer podia acionar a falha e executar código arbitrário no contexto do usuário logado — e o detalhe que tornou isso grave em 2014 é que o bypass funcionava mesmo com o Enhanced Protected Mode do IE e o EMET da Microsoft ativados, dois controles que a indústria considerava barreiras confiáveis contra exatamente esse tipo de exploração.

A função de redimensionamento de arrays (SafeArrayRedim, chamada de SafeArrayDimen na descrição oficial da CVE) trata o valor de tamanho de um SAFEARRAY sem validação adequada quando ocorre um erro durante a operação. Isso é classificado como CWE-119 (restrição incorreta de operações dentro dos limites de um buffer de memória): o tamanho inconsistente permite que a rotina escreva ou leia além do buffer alocado, corrompendo memória adjacente de forma que o atacante pode influenciar.

O vetor prático é VBScript executado dentro do Internet Explorer, que chama a API de redimensionamento de array com parâmetros forjados para forçar a condição de erro e a subsequente checagem de tamanho falha. Como o OleAut32.dll é uma DLL de sistema usada por qualquer componente que dependa de OLE Automation, o pesquisador que reportou a falha (Robert Freeman, IBM X-Force) destacou que o código vulnerável existia na base do Windows há muito tempo — o vetor de exploração via IE/VBScript foi o que tornou a falha remotamente explorável de forma prática.

O que torna essa CVE notável tecnicamente não é a classe de bug (corrupção de memória em parser/handler de tamanho é comum), mas o fato de que a técnica de exploração conseguia contornar tanto o sandbox Enhanced Protected Mode do IE quanto o EMET — dois controles de mitigação de exploração que a Microsoft recomendava como defesa em profundidade contra esse tipo de RCE.

O vetor é drive-by: uma página web maliciosa com VBScript embutido, aberta no Internet Explorer, dispara a condição de redimensionamento de array que corrompe memória. Não é necessária autenticação nem configuração fora do padrão — basta o usuário visitar a página no navegador vulnerável (UI:R no vetor CVSS, refletindo a necessidade de interação). O impacto final é execução de código no contexto do usuário corrente; se esse usuário tiver privilégios administrativos, o comprometimento é total.

Existe módulo Metasploit público (referenciado por um script Ruby publicado logo após a divulgação) e prova de conceito documentada, o que reduziu bastante a barreira técnica para exploração em massa já em novembro de 2014. A CISA incluiu a CVE no catálogo KEV (Known Exploited Vulnerabilities) em março de 2022, com prazo de correção em abril de 2022 — evidência de exploração ativa confirmada, mesmo quase oito anos após o patch original, tipicamente contra sistemas Windows legados nunca atualizados. A entrada KEV não associa a falha a campanhas de ransomware conhecidas (campo listado como 'Unknown').

O detalhe operacional mais relevante para quem avalia risco hoje: o alvo primário é Internet Explorer com VBScript habilitado. Ambientes que já migraram para navegadores modernos sem suporte a VBScript, ou que desabilitaram scripting ativo no IE, têm a superfície de ataque original neutralizada — mesmo sem o patch aplicado.

A correção oficial é o boletim MS14-064 (KB3011443), que distribui a atualização 3006226 classificada como Crítica para todos os sistemas operacionais afetados — de Windows Server 2003 SP2 até Windows 8.1/Server 2012 R2 e Windows RT. Essa atualização substitui a atualização 2476490 emitida anteriormente em MS11-038. Aplicar essa atualização é a mitigação real; não há substituto equivalente.

Se a atualização não puder ser aplicada imediatamente, o paliativo documentado pelo CERT/CC é desabilitar conteúdo ativo (scripting, especialmente VBScript) no Internet Explorer, ou elevar a zona de segurança para 'Alto' nas zonas Internet/Intranet, forçando confirmação antes de executar scripts. Esse paliativo tem custo real: quebra páginas internas ou legadas que dependem de VBScript/ActiveX, algo comum em intranets corporativas antigas.

O mito a descartar: confiar no EMET ou no Enhanced Protected Mode do IE como mitigação suficiente não funciona aqui — a própria vulnerabilidade foi demonstrada contornando esses dois controles, que eram vendidos como defesa em profundidade contra RCE em navegador. Nenhum WAF ou controle de borda de rede mitiga essa falha, pois a exploração ocorre inteiramente no processo do navegador no endpoint.

Não há assinatura de rede confiável: a exploração ocorre inteiramente dentro do processo do Internet Explorer no endpoint, via VBScript entregue por HTTP/HTTPS normal, sem payload facilmente distinguível de tráfego web legítimo. Os sinais mais úteis são no endpoint: falhas do iexplore.exe com referência a OleAut32.dll em logs de Windows Error Reporting, EDR/AV sinalizando exploração de memória em processos de navegador, ou detecção de payloads conhecidos do módulo Metasploit público (que tem assinaturas catalogadas por diversos fornecedores de AV/EDR). Ambientes que monitoram processos filhos anômalos gerados por iexplore.exe (indicador clássico de drive-by RCE) têm mais chance de capturar tentativas de exploração do que quem depende só de inspeção de tráfego.