CVE-2010-3962: O Use-After-Free do IE Que Iniciou a Era Moderna de Exploração de Navegadores

Em novembro de 2010, enquanto a maioria da comunidade de segurança ainda debatia cadências de patches, atacantes já estavam entregando execução de código via drive-by em sistemas Windows XP totalmente patchados através de nada mais exótico que uma página maliciosa — e Microsoft não tinha patch pronto nem por perto duas semanas após a divulgação pública.

🎯 Impacto: Execução remota de código via HTML/CSS malicioso no Internet Explorer 6, 7 e 8
🔓 Vetor de Ataque: Rede (sem cliques após carregamento da página)
💥 Exploração: Moderada (requer heap spray; técnica bem documentada em 2010)
🛡️ Correção Disponível: Sim — MS10-090 (dezembro de 2010)
⏱️ Aplicar Patch Agora: Apenas sistemas legados — IE/Edge moderno não afetado

O Que Está Realmente Acontecendo

O ponto é esse — vulnerabilidades use-after-free têm reputação de serem "complexas". CVE-2010-3962 é um case study perfeito de por que essa reputação é enganosa. A mecânica é elegante de um jeito sombriamente eficiente.

A causa raiz está em como o mecanismo de renderização CSS do Internet Explorer gerenciava o ciclo de vida de objetos DOM durante a recalculação de estilos. Especificamente, o bug envolve o atributo CSS clip e como IE processava certas sequências de tokens CSS que desencadeavam destruição de objetos enquanto uma referência a esse objeto ainda estava na call stack.

Quando IE parseava uma regra CSS contendo a propriedade clip em uma sequência específica, podia desencadear uma re-avaliação da folha de estilos que causava um objeto de layout ser liberado da memória antes do código que originalmente o referenciava terminar a execução. Esse ponteiro flutuante — agora apontando para memória heap desalocada — era subsequentemente usado como se o objeto ainda fosse válido.

O padrão conceitual parece algo assim:

// Padrão conceitual simplificado — NÃO é código fonte real do IE
void CSSStyleProcessor::applyClipAttribute(LayoutObject* obj) {
    // obj é válido aqui
    triggerStyleRecalculation();  // <-- ISSO pode destruir obj internamente
    
    // obj pode estar agora liberado — mas não sabemos disso
    obj->updateFlags();  // USE-AFTER-FREE: leitura/escrita em memória desalocada
}

A chamada triggerStyleRecalculation() é a killer. É uma operação re-entrante — pode disparar eventos, atualizar o DOM e destruir objetos. Se a sequência CSS for elaborada para causar essa re-entrância no momento precisamente errado, o objeto obj é liberado durante a chamada, e a dereferência subsequente opera em memória que o atacante agora pode influenciar.

Por que esse bug existe? É uma falha clássica de gerenciamento de lifetime em C++. O mecanismo de renderização foi escrito com uma suposição implícita de que certas operações eram não-destrutivas, então nenhuma verificação de propriedade foi realizada antes de dereferências subsequentes. Sem reference counting. Sem verificações de validade. Apenas um ponteiro raw e confiança otimista.

Se você viu CVE-2010-0249 (a vulnerabilidade Aurora do IE do início daquele mesmo ano, usada contra Google), isso vai parecer familiar. Aurora era também um use-after-free no tratamento de eventos do IE. A comunidade de segurança explicitamente alertou Microsoft que o padrão de reutilização de ponteiros raw no mecanismo de renderização do IE era sistêmico — esse CVE é evidência de que o alerta não foi heeded rápido o suficiente.

Caminho de Exploração

A cadeia de ataque aqui é praticamente 2010-era de exploração de navegador, e entender isso explica por que foi tão perigoso na prática.

Pré-requisitos: Zero autenticação necessária. A vítima só precisa visitar uma página. Nenhum prompt de download de arquivo, nenhum aviso de segurança, nenhum click-through. Isso é tão passivo quanto fica.

Passo a passo:

1. Atacante hospeda uma página contendo JavaScript que realiza um heap spray — inundando o heap do IE com NOP sleds e shellcode em endereços de memória previsíveis (tipicamente ao redor de 0x0c0c0c0c).
2. CSS malicioso está incluído na página com um atributo clip elaborado projetado para disparar a recalculação de estilos re-entrante.
3. Mecanismo CSS do IE bate no caminho de código vulnerável, libera o objeto de layout e então derreferencia o ponteiro flutuante.
4. A dereferência pousa em memória heap com spray porque o spray tornou esses endereços previsíveis e populados.
5. Shellcode executa no nível de privilégio do processo IE — em XP, isso é efetivamente o usuário conectado sem sandbox.

Os cenários de ataque do mundo real documentados em novembro de 2010 envolviam ataques watering hole — websites legítimos comprometidos injetando o exploit em páginas caso contrário confiáveis. Seu intranet corporativo, seu site de notícias, seu portal de vendor. A vítima não foi a lugar suspeito algum.

Quem Está Realmente Em Risco

Por fim de 2010, o perfil de risco era severo mas não universal. Aqui está a análise honesta:

• Windows XP + IE 6/7/8: Exposição máxima. Sem ASLR, sem sandbox de Protected Mode (XP não suporta), sem stack de mitigação de exploit significativa. Aqui é onde os ataques in-the-wild estavam se concentrando.
• Windows Vista/7 + IE 8: Ainda vulnerável ao UAF, mas DEP e ASLR elevam a barra consideravelmente. Exploração requer uma cadeia ROP funcionante. Ainda viável para um atacante motivado, mas não território script-kiddie.
• Ambientes empresariais: Os alvos de maior risco, porque a adoção de XP ainda era massiva em 2010 (mantinha ~60% de market share desktop globalmente) e ciclos de patch corporativos eram lentos.
• Usuários XP consumidores com atualizações automáticas: Em risco até MS10-090 ser enviado em 14 de dezembro de 2010 — mais de duas semanas após divulgação pública.

As indústrias que deveriam ter estado mais alarmadas: serviços financeiros, governo, contractors de defesa. O vetor watering hole significa que você não precisa fazer phishing do alvo diretamente — você compromete um site que eles confiam e espera.

Isso estava sendo ativamente explorado in-the-wild antes mesmo do CVE ser atribuído publicamente. Isso não é uma avaliação teórica de risco — isso é dado confirmado de resposta a incidentes de novembro de 2010.

Detecção & Hunting

Se você está rodando um ambiente legado que ainda tem IE8 (e sim, esses ainda existem em contextos industriais e governamentais), aqui está como a exploração parece:

Indicadores comportamentais:

• Processo IE gerando processos filhos inesperados (cmd.exe, powershell.exe, ferramentas de rede)
• IE fazendo conexões outbound para portas não-web imediatamente após carregamento de página
• Padrões heap spray: JavaScript alocando buffers de strings grandes e repetitivos antes de manipulação DOM

Lógica de detecção Sigma conceitual:

title: Potencial Comportamento Pós-Exploração de CVE-2010-3962
status: experimental
description: Detecta IE gerando processos filhos suspeitos indicativos de exploração UAF
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith: '\iexplore.exe'
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\wscript.exe'
            - '\mshta.exe'
    condition: selection
falsepositives:
    - Extensões legítimas do IE que geram processos helper
level: high
tags:
    - attack.execution
    - attack.t1203

Em seu SIEM: Procure por iexplore.exe como processo pai para qualquer coisa que não seja outro processo frame do IE. Em 2010, a maioria dos deployments de SIEM não estava monitorando relacionamentos pai-filho — uma de muitas razões pelas quais isso passou despercebido na época.

Playbook de Mitigação

1. Imediato — Aplicar MS10-090 Microsoft lançou o fix em dezembro de 2010 como parte de seu ciclo Patch Tuesday. Se você tem qualquer sistema ainda rodando IE 6/7/8 não patchado em XP/2003/Vista/7, faça o patch. Ponto.

2. Curto prazo se patching é impossível:

• Enable DEP para IE: Mesmo sem o patch, Data Execution Prevention elevou significativamente a barra de exploração em Vista+.
• Defina Internet Zone security para High: Desabilita a capacidade de heap spray JavaScript que torna exploração confiável possível.
• Deploy EMET (Enhanced Mitigation Experience Toolkit): Ferramenta gratuita de mitigação da Microsoft foi explicitamente recomendada para esse CVE e teria bloqueado a maioria das tentativas de exploração via enforcement de DEP e detecção de heap spray.
• Considere migração IE → Chrome/Firefox: Se você ainda está em IE8 em um ambiente corporativo em 2010, esse CVE é seu forcing function.

3. Endurecimento a longo prazo:

• Saia do Windows XP completamente (EOL abril de 2014 — esse CVE deveria ter acelerado aquela timeline).
• Enforce application whitelisting para prevenir execução arbitrária de código mesmo se exploração sucede.
• Nível de rede: Bloqueie conexões outbound de processos navegador para portas não-standard.

4. Verificação: Execute uma consulta rápida de inventory para quaisquer sistemas ainda rodando versões IE ≤ 8 sem MS10-090 aplicado (KB2416400). Se você encontrar alguns, você tem um problema muito maior que esse único CVE.

Minha Análise

Se sou honesto, o rating CVSS 8.1 é tecnicamente defensível mas emocionalmente diminui o que essa vulnerabilidade significou em contexto. Em novembro de 2010, um score de 8.1 pode fazer um CISO pensar "importante mas não crítico". A realidade era: isso era um zero-day sendo ativamente armedizado contra alvos corporativos sem patch disponível. Em frameworks de scoring moderno, a exploração ativa sem patch disponível empurraria o risco do mundo real para 10/10 urgência independentemente do score base.

O que torna essa vulnerabilidade significativa historicamente não é apenas o bug técnico — é o que revelou sobre o estado da arquitetura de segurança de navegadores. O mecanismo de renderização do IE estava repleto de uso de ponteiros raw e suposições implícitas de lifetime. Aurora aconteceu em janeiro de 2010. CVE-2010-3962 aconteceu em novembro de 2010. A mesma classe de vulnerabilidade, o mesmo navegador, os mesmos dez meses de "estamos trabalhando nisso". A comunidade de segurança precisava se mover de tratar cada UAF como um incidente isolado para reconhecer que a codebase em si era a vulnerabilidade.

A resposta de Microsoft merece crítica aqui. Duas semanas entre divulgação pública de um zero-day ativamente explorado e um patch é muito tempo. As mitigações para as quais apontaram usuários (EMET, DEP, configurações de zona de segurança) eram ou não amplamente deploadas ou requeriam sofisticação técnica que a maioria dos usuários não tinha. A lição real para a comunidade de segurança: exploração in-the-wild de um zero-day de navegador deveria desencadear patching out-of-band de emergência, não esperar o próximo Patch Tuesday. Microsoft eventualmente aprendeu isso. Esse CVE é parte do que os ensinou.

Timeline

Referências

• CVE-2010-3962 — Entrada Oficial NVD — Scoring base e dados CPE
• CWE-416: Use After Free — Classificação de fraqueza e padrões
• Microsoft Security Advisory 2458511 — Divulgação original Microsoft e guidance de workaround
• Boletim MS10-090 — Documentação oficial de patch
• Histórico de Módulo Metasploit — Documentação de módulo Rapid7 ilustrando timeline de weaponização
• Análise de CVE-2010-0249 (Aurora) — Vulnerabilidade predecessor no mesmo padrão de UAF do IE