CVE-2010-3765: Quando o Motor de Layout do Firefox Virou Uma Máquina de Download Malicioso

Em outubro de 2010, os atacantes não precisavam de um e-mail de phishing, um anexo malicioso, ou qualquer engenharia social além de "visite este website." Um carregamento de página no Firefox desatualizado era tudo o que era necessário para comprometer uma máquina—e a campanha de malware Belmoo provou que isso não era apenas teórico.

🎯 Impacto: Execução remota de código via corrupção de memória no construtor de frames CSS do Firefox
🔓 Vetor de Ataque: Rede (download malicioso, zero interação do usuário além de visitar uma página)
💥 Exploitabilidade: Moderada (requer JavaScript, heap spray típico—bem dentro das capacidades do atacante)
🛡️ Correção Disponível: Sim (Firefox 3.5.15 / 3.6.12, Thunderbird 3.0.10 / 3.1.6, SeaMonkey 2.0.10)
⏱️ Aplicar Patch: Irrelevante para a maioria—essas versões têm mais de uma década de EOL. Se você ainda está rodando essas versões, aplicar patch é o menor de seus problemas.

O Que Está Acontecendo Na Verdade

O ponto é esse sobre vulnerabilidades de navegador: as mais perigosas não vivem em recursos obscuros. Elas vivem no motor que é executado toda vez que você carrega uma página web. CVE-2010-3765 atinge exatamente esse tipo de maquinaria central—o subsistema de construção de frames CSS.

A causa raiz é um bug de rastreamento de índice incorreto dentro de nsCSSFrameConstructor::ContentAppended, a função do motor de layout Gecko responsável por construir a árvore de frames visuais quando novos nós DOM são adicionados a um documento. Quando JavaScript chama appendChild() para inserir nós no DOM, ContentAppended precisa percorrer a lista de frames existente e calcular o ponto de inserção correto. A vulnerabilidade surge porque sob certas condições envolvendo múltiplos tipos de frames sendo criados simultaneamente, o índice interno usado para rastrear a posição na árvore de frames fica corrompido.

Pense assim: o construtor de frames do Gecko mantém uma lista de "frames" (objetos internos de layout, não elementos HTML <frame>) que correspondem aos nós DOM. Quando você anexa um nó filho, o motor calcula onde na lista de frames inserir o novo frame. Se você manipula o DOM de forma a forçar o construtor a criar múltiplos frames para o que ele esperava ser uma inserção mais simples—certas propriedades CSS, geração de caixas anônimas, ou divisão de frames relacionados a tabelas podem todos desencadear isso—o contador de índice em execução fica fora de sincronização com o estado da lista de frames real.

O padrão vulnerável conceitualmente se parece com isto:

// Representação conceitual do padrão de disparo
// NÃO é um exploit funcional

// 1. Configurar um contêiner com propriedades CSS específicas que 
//    forçam geração de múltiplos frames na anexação
let container = document.createElement('div');
container.style.display = 'table'; // ou propriedade similar que divide frames
document.body.appendChild(container);

// 2. Disparar ContentAppended com um nó que faz o construtor de frames
//    criar mais frames do que esperado
for (let i = 0; i < N; i++) {
    let child = document.createElement('span');
    container.appendChild(child);  // Cada chamada desvia o índice interno
}

// 3. O desajuste de índice eventualmente causa uma escrita
//    para um local de memória incorreto → corrupção de heap

O perigo real é o que essa corrupção possibilita: primitivas de escrita arbitrária. Uma vez que você controla o que é escrito e onde no heap, técnicas clássicas de heap spray permitem pré-popular a memória com shellcode e redirecionar a execução para ela. Isso era 2010—pré-ASLR obrigatório na maioria dos sistemas Windows XP, pré-SLFH confiável (Segment Heap), e antes do Firefox ter mitigações significativas de exploração. A superfície de exploit estava amplamente aberta.

Isto pertence completamente a CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer)—mas a nuance interessante é que este não é um simples buffer overflow. É um erro de indexação lógico que produz uma violação de segurança de memória. A distinção importa quando você está caçando bugs similares: você não pode grep por strcpy e encontrar este.

Caminho de Exploração

A beleza (da perspectiva do atacante) dessa vulnerabilidade é como a cadeia de exploração é limpa. Sem autenticação. Sem conta. Sem software instalado. Apenas um navegador.

Pré-requisitos: JavaScript ativado (padrão), Firefox 3.5.x–3.6.x ou equivalentes Thunderbird/SeaMonkey, vítima visita página controlada pelo atacante. É isso.

A Cadeia de Ataque:

1. Atrair — O atacante hospeda HTML/JS malicioso em um servidor web, ou injeta em um site legítimo comprometido. Redes de publicidade maliciosa foram particularmente eficazes aqui.

2. Disparar o bug — JavaScript executa chamadas appendChild no padrão específico que corrompe o índice interno do construtor de frames. O navegador não trava imediatamente; continua executando com um estado de heap corrompido.

3. Heap spray — Antes ou depois de disparar a corrupção, o JS do atacante pré-enche o heap com NOP sleds e shellcode usando typed arrays grandes ou alocações de string. No Windows XP sem ASLR, endereços de heap previsíveis tornam isso confiável.

4. Redirecionar execução — O índice corrompido resulta em uma escrita para um local de memória controlado—tipicamente sobrescrevendo um ponteiro de função, entrada vtable, ou endereço de retorno. Quando esse caminho de código é executado novamente, o controle é transferido para o spray.

5. Entrega de payload — A campanha Belmoo usou isso para comportamento clássico de dropper: baixar e executar um payload secundário. Game over.

O que o atacante obtém na etapa 5: Execução de código em nível SYSTEM se o navegador está rodando elevado (comum no XP), ou no mínimo execução em nível de usuário com acesso aos arquivos, credenciais e posição de rede da vítima.

Quem Realmente Está Em Risco

Em 2010? Todos rodando Firefox no Windows. Os números de participação de mercado daquele período colocavam o Firefox em torno de 25-30% globalmente. A campanha Belmoo especificamente visava usuários Windows e foi observada na natureza antes mesmo da Mozilla ter um patch pronto—significando que este era um evento de exploração zero-day, não um ataque n-day.

As indústrias mais atingidas na campanha Belmoo pareciam ser direcionamento amplo a consumidores em vez de spear-phishing, mas qualquer organização onde os funcionários pudessem navegar em websites arbitrários estava exposta.

Hoje? Se você de alguma forma tem Firefox 3.5 ou 3.6 rodando no seu ambiente em 2024, você tem problemas muito maiores do que este CVE. Estamos falando de software end-of-life de 14 anos atrás. O risco realista hoje é:

• Sistemas embarcados legados onde navegadores estão congelados em versões antigas (quiosques, HMIs industriais, alguns equipamentos de saúde)
• Imagens VM abandonadas que são iniciadas sem ciclos de atualização
• Relevância forense—entender essa vulnérabilidade ajuda você a analisar malware dessa era

Detecção & Busca

Para análise forense histórica ou ambientes onde versões antigas do Firefox realmente estão rodando:

Como exploração se parece nos logs:

• Spawn súbito de processo filho de firefox.exe com argumentos de linha de comando incomuns
• Conexões de rede iniciadas por firefox.exe para IPs externos inesperados imediatamente após carregamento de página
• Artefatos de heap spray: alocações grandes de blocos de memória idênticos visíveis em crash dumps

Lógica de detecção conceitual:

# Regra estilo Sigma (conceitual, não validada para produção)
title: Spawning Suspeito de Processo Filho do Firefox
status: historical
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith: '\firefox.exe'
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\wscript.exe'
            - '\cscript.exe'
    filter:
        CommandLine|contains: 'extension'  # Reduzir FP para instaladores de addon
    condition: selection and not filter
falsepositives:
    - Mecanismos de atualização do Firefox (validar contra caminhos de atualização conhecidos-bons)
level: high
tags:
    - attack.execution
    - attack.t1203  # Exploração para Execução de Cliente

IOCs da era Belmoo em grande parte estão queimados neste ponto (infraestrutura C2 de 14 anos atrás), mas a assinatura comportamental—navegador spawning um processo downloader pouco tempo após visitar um site—continua sendo o indicador canônico para essa classe de exploit drive-by.

Playbook de Mitigação

1. Imediato: Atualizar para Firefox 3.5.15, 3.6.12 (ou idealmente, um lançamento suportado atual—Firefox 3.x não recebe atualizações de segurança desde 2012). O mesmo para Thunderbird 3.0.10/3.1.6 e SeaMonkey 2.0.10.

2. Se você não consegue fazer patch (sistemas embarcados/legados): Desabilite JavaScript nas preferências do navegador. Isso elimina completamente o vetor de ataque já que JS é necessário para disparar appendChild no padrão exploitável. Não é prático para navegação geral mas apropriado para cenários de quiosque bloqueado.

3. Nível de rede: Proxies web com inspeção de conteúdo podem bloquear páginas contendo os padrões de JS de disparo, embora evasão de assinatura fosse trivial em 2010 e continua sendo.

4. Longo prazo: Se você tem qualquer sistema rodando Firefox < 50 no seu ambiente, deve ser tratado como totalmente comprometido até ser atualizado. Enumerar via SCCM/Ansible/gerenciamento de endpoint—você pode se surpreender com o que anda escondido na sua frota.

5. Verificar que você está protegido: firefox --version da linha de comando. Qualquer coisa abaixo de 3.5.15 na série 3.5.x ou 3.6.12 na série 3.6.x é vulnerável. Na prática, se você não está no Firefox 120+, você tem dúzias de CVEs críticos sem patch independentemente.

Minha Análise

O CVSS 9.8 é preciso—e se algo, subestima levemente o impacto real na época. CVSS não leva em conta a maturidade de exploração ou o contexto do ecossistema. Em outubro de 2010, Windows XP era o sistema operacional dominante, ASLR não era consistentemente obrigatório, e heap sprays eram quase-determinísticos. A exploitabilidade prática era mais próxima de "território script kiddie" uma vez que o código de exploit inicial circulava, não "atacante sofisticado necessário."

O que torna CVE-2010-3765 historicamente significativo é o que representa sobre a era de download drive-by. Esse não foi o primeiro exploit de navegador, e não foi o mais sofisticado. Mas é um exemplo de manual de como erros lógicos em motores de layout—não primitivas de gerenciamento de memória como malloc ou free—podem produzir corrupção de memória exploitável. O bug não está em código de manipulação de memória. Está em aritmética de índice. Essa é a percepção que importa: você pode auditar toda alocação e desalocação em uma base de código e ainda perder essa classe de bug inteiramente.

A resposta da Mozilla foi na verdade razoavelmente rápida considerando a era—aproximadamente uma semana de exploração-na-natureza para patch. Mas a lição que a indústria deveria ter tirado é que enviar um patch não é suficiente. As taxas de adoção de patch para vulnerabilidades de navegador em 2010 eram deploráveis. Usuários e organizações rodando navegadores meses atrás da versão atual era a norma, não a exceção. A correção sistêmica real veio depois com mecanismos de auto-atualização silenciosos em segundo plano que Firefox, Chrome e outros eventualmente implementaram. CVE-2010-3765 faz parte da história que justificou remover o usuário da decisão de atualização inteiramente.

Cronologia

Referências

• CVE-2010-3765 — Entrada NVD — Registro oficial com dados CPE
• CWE-119 — Improper Restriction of Operations within Buffer Bounds — Classificação de fraqueza de causa raiz
• Mozilla Security Advisory MFSA 2010-73 — Aviso oficial do fornecedor com detalhes do patch
• Gecko Layout Engine Architecture — Histórico sobre o subsistema construtor de frames afetado
• MITRE ATT&CK T1203 — Exploração para Execução de Cliente — Classificação de técnica para exploração drive-by