CVE-2012-4792
Patch now. It under exploitation confirmed by CISA, has a working public exploit and 1 threat group(s) use it.
Groups known to exploit this vulnerability (MITRE ATT&CK attribution).
The impacted product is end-of-life and should be disconnected if still in use.
Summary
Use-after-free na mshtml.dll do Internet Explorer 6, 7 e 8, permitindo execução remota de código quando a vítima visita uma página maliciosa. A falha foi explorada em ataques direcionados (watering hole) contra o site do Council on Foreign Relations em dezembro de 2012, antes de qualquer patch existir, o que a torna uma das raras CVEs onde 'exploração ativa' significa literalmente 0-day em campanha de espionagem, não scanner automatizado em massa.
Technical detail
A vulnerabilidade está no gerenciamento de memória de objetos da mshtml.dll ligados ao elemento renderizado pelo IE (CWE-416, use-after-free). JavaScript malicioso força a liberação de um objeto — a Microsoft e a Vulnerability Note VU#154201 identificam como o objeto CButton, enquanto a descrição oficial da CVE e parte da cobertura inicial (blog vulnhunt, cobertura da própria NVD) referenciam CDwnBindInfo; o módulo Metasploit e o CERT/CC tratam o CButton como o objeto efetivamente disparado no exploit em circulação. Após a liberação, uma referência (ponteiro) ao objeto não é zerada, e uma ação subsequente do atacante — tipicamente um reload ou reflow forçado da página — faz o motor de renderização chamar um endereço de memória inválido através desse ponteiro pendente.
O atacante não controla diretamente o conteúdo daquele endereço via a falha em si; controla-o indiretamente através de técnicas de heap grooming/spray. Nos exploits observados, Adobe Flash foi usado para pulverizar a heap com dados controlados no endereço que seria reaproveitado, e um applet Java foi usado para carregar gadgets de ROP (Return Oriented Programming) na memória, contornando DEP em sistemas sem ASLR eficaz (como Windows XP e Server 2003) ou complementando ASLR em versões mais novas. Isso implica que a exploração completa e confiável, como vista in-the-wild, dependia da presença de Flash e Java habilitados no IE — não apenas do bug em si.
How it’s exploited
Vetor: página web (ou documento HTML/e-mail com HTML embutido, conforme aponta o CERT/CC) que a vítima precisa abrir no IE vulnerável — exige interação do usuário (visitar o site ou clicar em link/anexo), sem necessidade de autenticação prévia. A campanha documentada por FireEye e AlienVault em dezembro de 2012 foi um ataque watering hole: o site do Council on Foreign Relations foi comprometido e servia o exploit apenas para visitantes com determinadas configurações de idioma/navegador, sugerindo direcionamento geográfico (relatos apontam foco em vítimas na China, Taiwan e EUA).
A cadeia de exploração real combinava três componentes: o gatilho JavaScript do use-after-free no mshtml, heap spray via Flash para posicionar dados controlados na memória liberada, e um applet Java para fornecer gadgets ROP que desviam a execução para o payload sem precisar de shellcode executável direto (contorno de DEP). Isso eleva a complexidade prática do ataque, mas não sua confiabilidade — PoCs públicas circularam rapidamente, inclusive variantes sem heap spray via Flash, o que ampliou a superfície de reuso por outros atores após a divulgação inicial.
O resultado final é execução arbitrária de código no contexto do usuário logado (não elevação automática de privilégio). Como o exploit foi weaponizado antes do patch oficial, o CVE está no catálogo KEV da CISA e há módulo funcional no Metasploit (ie_cbutton_uaf.rb), tornando reprodução trivial para quem ainda mantém IE 6-8 sem correção.
Versions
How to protect
A correção definitiva é o boletim MS13-008 da Microsoft, lançado fora do ciclo normal de Patch Tuesday (janeiro de 2013) justamente pela exploração ativa. Ambientes que ainda rodam IE 6, 7 ou 8 sem esse patch — cenário hoje restrito a sistemas legados isolados, já que essas versões estão fora de suporte há anos — permanecem vulneráveis; a mitigação real é aplicar o update do MS13-008 ou, definitivamente, remover/substituir o IE 6-8 do ambiente.
Enquanto o patch definitivo não existia, a Microsoft distribuiu um 'Fix It' temporário que fazia o IE falhar de forma controlada (crash) em vez de executar código na tentativa de exploração — mas a própria Exodus Intel demonstrou bypass desse Fix It, então ele não deve ser tratado como mitigação equivalente ao patch, apenas como redução de risco transitória. Como controles compensatórios documentados pelo CERT/CC: usar o EMET (com eficácia reduzida em XP/Server 2003, que não têm ASLR completo), desabilitar o ActiveX do Flash no IE via kill bit de CLSID, e desabilitar conteúdo Java no navegador — nenhuma dessas medidas corrige a falha de mshtml, mas quebra a cadeia de exploração observada (heap spray via Flash e ROP via Java), reduzindo a chance de exploração confiável sem eliminar o bug.
O que não funciona: assumir que atualizar apenas Flash ou Java resolve o problema — a vulnerabilidade é no próprio Internet Explorer/mshtml, e esses componentes são apenas facilitadores da técnica de exploração, não a causa raiz.
How to detect
Em log de servidor web ou proxy, buscar acessos a páginas comprometidas conhecidas da campanha original (o site do Council on Foreign Relations foi o caso documentado publicamente) partindo de User-Agents IE 6-8, especialmente combinados com carregamento simultâneo de objetos Flash e applets Java na mesma sessão — padrão atípico para a maioria dos sites legítimos. Em endpoint, crashes do iexplore.exe ou do processo Flash/Java plugin-container sem causa aparente, ou o disparo do Fix It da Microsoft (que gera evento de crash controlado), são indícios de tentativa de exploração; como a técnica varia (há PoCs sem heap spray via Flash), não existe assinatura de rede única e confiável — a detecção depende mais de EDR observando comportamento anômalo do mshtml.dll do que de padrões estáticos de payload.