CVE-2012-4681

Falha crítica na Java Runtime Environment 7 (JRE 7) que permite a um applet Java malicioso escapar completamente do sandbox do SecurityManager e executar código arbitrário na máquina da vítima, sem qualquer interação além de visitar uma página web com o plugin Java habilitado no navegador. Foi explorada in-the-wild como 0-day em agosto de 2012 antes de qualquer correção existir, e o CVSS 9.8 reflete bem a realidade: pré-condição única é ter o plugin Java 7 ativo no browser.

A vulnerabilidade combina dois bugs de controle de acesso (CWE-284/CWE-470) na classe com.sun.beans.finder.ClassFinder, introduzida no Java 7 (lançado em julho de 2011). O método findClass usa internamente Class.forName, e uma condição de exceção mal tratada permite que código não confiável (o applet) obtenha uma referência à classe sun.awt.SunToolkit — que pertence a um pacote restrito (sun.*) e normalmente é inacessível para código sandboxed.

Com a referência a SunToolkit em mãos, o exploit invoca o método público estático getField, que roda internamente dentro de um bloco AccessController.doPrivileged e usa reflection para chamar setAccessible(true) em campos privados de qualquer classe. Como a chamada tem 'um caller imediato confiável' (o próprio SunToolkit, que é código de sistema), o Java não bloqueia o acesso, mesmo vindo originalmente de um applet não confiável — esse é o segundo bug.

Com acesso de escrita a campos privados liberado, o exploit localiza o campo privado final 'acc' (um AccessControlContext) dentro de instâncias de java.beans.Statement. Esse campo havia sido adicionado como correção de uma vulnerabilidade anterior (CVE-2010-0840) exatamente para impedir 'trusted method chains'. O exploit sobrescreve esse AccessControlContext por um ProtectionDomain com permissões totais (AllPermission) e então executa o Statement — que passa a rodar com privilégios completos, efetivamente desligando o SecurityManager para o restante da execução do applet.

A partir daí não há mais sandbox: o applet pode ler/escrever arquivos, executar processos e carregar bibliotecas nativas como qualquer aplicação Java confiável. Segundo análise de Michael Schierl (DeepEnd Research), o bug de reflection não existe no Java 6 porque getField era privado naquela linha; há relato não confirmado de que builds específicos de OpenJDK 6 com backport (ex.: update 25) poderiam conter o código vulnerável, mas isso não foi validado pelo fornecedor.

O vetor é um applet Java hospedado em página web (ou injetado via malvertising/comprometimento de site) que a vítima carrega em um navegador com o plugin Java 7 ativo — não há necessidade de autenticação, configuração não padrão ou qualquer clique além de abrir a página. A exploração observada em agosto de 2012 usava duas classes específicas, Gondzz.class e Gondvv.class, que executavam a cadeia descrita e em seguida baixavam e instalavam o RAT Poison Ivy na máquina da vítima.

Uma PoC funcional foi divulgada publicamente por Joshua J. Drake dias após a descoberta da campanha, e a Rapid7 lançou módulo Metasploit em 27 de agosto de 2012, um dia antes da correção da Oracle — o que ampliou rapidamente o uso da falha além do grupo original de atacantes, incluindo relatos da época de incorporação a exploit kits comerciais. A confiabilidade é alta e o exploit funciona de forma multiplataforma (Windows, Linux, qualquer SO com JRE 7 vulnerável e plugin de browser habilitado), já que a lógica abusada está inteiramente na camada Java, não no SO.

O resultado final da exploração é execução de código arbitrário com os privilégios do usuário que executa o navegador — sem elevação automática de privilégios de sistema; em contas de usuário padrão sem privilégios administrativos, o impacto fica limitado ao contexto desse usuário, embora isso não tenha sido testado exaustivamente pelos pesquisadores da época.

A correção do fornecedor é a atualização para Oracle Java SE 7 Update 7 (7u7), lançada em caráter emergencial em 30 de agosto de 2012, dois dias após a confirmação de exploração ativa — fora do ciclo trimestral normal de patches da Oracle. Distribuições Linux replicaram a correção em pacotes derivados: Red Hat corrigiu via RHSA-2012:1225 (java-1.7.0-oracle, RHEL 6 Supplementary) e openSUSE via os avisos de setembro/outubro de 2012 referenciados. Todas as instâncias em execução da JVM precisam ser reiniciadas para que a correção tenha efeito.

Se a atualização imediata não for possível, o único paliativo real documentado na época — inclusive recomendado pelo US-CERT — é desabilitar ou desinstalar o plugin Java do navegador, já que não havia solução prática de configuração conhecida para o problema em si. Isso elimina o vetor de ataque via applet mas não afeta aplicações Java desktop standalone, que não são expostas a este vetor específico.

Verificar apenas a string de versão exibida por checadores automáticos da época não é garantia suficiente: ferramentas de verificação rápida (como a citada da Zscaler) tiveram falsos positivos/negativos nos primeiros dias após o patch. O critério real é a versão exata do runtime instalado (7u7 ou posterior) e, para builds OpenJDK, a presença ou não do backport corrigido de com.sun.beans.finder.ClassFinder.

Não há assinatura de rede única e confiável, já que o exploit pode ser recompilado e obfuscado livremente (o próprio módulo Metasploit gera variações), e a lógica de exploração ocorre inteiramente dentro da JVM, sem tráfego de rede distintivo até a etapa de download de payload. Os indicadores conhecidos da campanha original de 2012 são o download de arquivos .jar contendo as classes Gondzz.class ou Gondvv.class e conexões subsequentes de C2 associadas ao RAT Poison Ivy; logs de proxy/IDS que capturaram o HTML/JS/applet original da campanha (mencionados pela DeepEnd Research) servem como IOC histórico, não como detecção genérica de novas variantes do exploit.