CVE-2012-0507

Falha de type confusion na implementação de AtomicReferenceArray do runtime Java (JRE/JDK), presente em Java SE 5.0 Update 33 e anteriores, 6 Update 30 e anteriores, e 7 Update 2 e anteriores. Permite que um applet Java malicioso escape completamente do sandbox do Java (SecurityManager), executando código com os privilégios do usuário que abriu a página — sem exigir autenticação nem interação alem de visitar um site. Foi amplamente explorada em 2012 para distribuir o trojan Flashback em Mac OS X e incorporada a kits de exploração como o Blackhole, o que justifica sua presença no catálogo KEV da CISA e o EPSS quase máximo.

O problema está na classe AtomicReferenceArray (java.util.concurrent.atomic), parte do pacote de concorrência do JRE. A implementação usa reflexão/Unsafe internamente para acessar o array subjacente, mas não valida que o array passado ao construtor seja de fato do tipo Object[]. Isso é um erro de verificação de tipo (type confusion, próximo de CWE-843/CWE-704) que quebra a garantia de type-safety da JVM.

A descrição oficial da Oracle chama isso de 'Concurrency' e não detalha o mecanismo — a atribuição ao componente de concorrência é do próprio fornecedor. A explicação técnica de como a falha realmente funciona (confusão de tipo em AtomicReferenceArray) vem de pesquisadores terceiros e de um fornecedor downstream, não da Oracle, e a Oracle nunca confirmou publicamente esse detalhe, segundo a nota do próprio registro CVE.

Com a confusão de tipo, um applet controla um array de tipo diferente do esperado internamente pela JVM. Isso permite manipular referências de objeto para obter uma referência arbitrária tipada incorretamente, o que na prática dá ao código do applet a capacidade de burlar as checagens do SecurityManager — o mecanismo que impede applets não confiáveis de acessar arquivos, rede ou executar processos fora da sandbox.

O histórico do CVE é conturbado: o identificador foi originalmente mapeado como CVE-2011-3571, mas esse número já pertencia a outra falha, forçando a reatribuição para CVE-2012-0507 e gerando confusão em bases de dados e advisories da época (visível, por exemplo, na numeração da CVSS entre boletins da HP para a mesma falha).

O vetor é um applet Java malicioso hospedado em uma página web (drive-by download) ou entregue via e-mail/anúncio malicioso. O usuário só precisa visitar a página com o plugin Java habilitado no navegador — não há necessidade de autenticação, de interação além de carregar a página, nem de configuração não padrão. Isso é coerente com o vetor de rede e a ausência de privilégios do CVSS (AV:N/AC:L/PR:N/UI:N).

Como a falha está no próprio JRE, e não em um componente específico de sistema operacional, o exploit funcionou de forma multiplataforma. O caso mais notório foi o uso da falha pelo trojan Flashback para infectar Macs sem exigir senha do usuário nem exploração adicional de kernel — bastava o Java Web Start/plugin do navegador estar desatualizado. A falha também foi incorporada rapidamente a kits de exploração comerciais (como o Blackhole), automatizando a entrega em massa contra qualquer JRE vulnerável encontrado durante fingerprinting do navegador.

A janela de exploração real foi ampliada porque a Oracle corrigiu a falha em seu Critical Patch Update de fevereiro de 2012, mas fornecedores downstream (notadamente a Apple, que na época mantinha sua própria build do Java para OS X) demoraram semanas para distribuir a correção, deixando um grande volume de sistemas expostos a exploração ativa mesmo após o patch oficial existir — daí a presença confirmada no catálogo KEV da CISA e a disponibilidade de módulo Metasploit e PoC pública.

A correção definitiva é atualizar para a versão de Java imediatamente posterior à faixa vulnerável publicada pela Oracle: Java SE 7 Update 3, 6 Update 31 ou 5.0 Update 34 (ou builds equivalentes distribuídas por fornecedores downstream, como os boletins da HP-UX que corrigem a mesma CVE em suas próprias numerações de JDK/JRE 5.0.25, 6.0.14 e 7.0.01 — essas numerações são específicas do empacotamento HP e não devem ser confundidas com o esquema 'Update N' da Oracle).

Se a atualização não for possível de imediato, o controle compensatório real e amplamente adotado na época foi desabilitar o plugin Java nos navegadores (ou removê-lo do sistema), já que o vetor de exploração depende de execução de applet no contexto do navegador. Isso elimina a superfície de ataque sem exigir alteração no JRE instalado, ao custo de quebrar qualquer aplicação web que dependa de applets Java.

Não funciona como mitigação apenas manter antivírus atualizado ou confiar em filtragem de conteúdo web genérica: como a falha está na JVM e não em um payload específico, variantes do exploit circularam ofuscadas em diferentes kits, driblando assinaturas. Sandboxing adicional de navegador ou bloqueio de execução de Java por política de grupo é mais eficaz do que detecção baseada em assinatura.

Não há assinatura de rede confiável e específica para esta CVE isoladamente, porque o exploit trafega como bytecode Java (classe/applet) dentro de conexões HTTP/HTTPS normais e foi reempacotado de forma ofuscada em múltiplos kits de exploração — bloquear por assinatura de payload tende a ter alta taxa de falso negativo contra variantes. Sinais úteis em endpoint: processo do plugin Java do navegador (javaws, java.exe ou processo do plugin do browser) travando ou gerando um processo filho inesperado (shell, downloader) imediatamente após a visita a uma página com applet; presença de arquivos .jar/.class temporários baixados pelo navegador antes de um comprometimento; e, em nível de rede, requisições a domínios associados a kits de exploração da época (Blackhole) buscando arquivos JAR seguidos de payload binário. Softwares de segurança da época (como Microsoft MMPC) classificaram detecções específicas ligadas a esta CVE, o que pode servir de referência histórica em logs antigos de EDR/AV.