CVE-2012-1723

Falha de type confusion no HotSpot (compilador cliente, C1) do Java SE que permite a um applet Java não confiável escapar completamente do sandbox da JVM e executar código arbitrário com os privilégios do usuário que roda o navegador. Foi uma das CVEs mais exploradas de 2012-2013, incorporada a kits de exploração comerciais (Blackhole, entre outros) para drive-by download em massa — daí estar no catálogo KEV da CISA e ter EPSS próximo de 1.0 mesmo mais de uma década depois.

O bug reside no compilador cliente do HotSpot (bug interno Sun/Oracle S7152811, tratado no OpenJDK/IcedTea e descrito pela Red Hat como "insufficient field accessibility checks (HotSpot, 7152811)"). O JIT do C1 falha em validar corretamente a acessibilidade de campos ao compilar certas sequências de bytecode, permitindo que código Java gerencie referências de tipo de forma inconsistente com o verificador de bytecode — um type confusion clássico da família de bugs de sandbox escape do Java daquele período (CWE de acesso indevido / verificação de tipo insuficiente).

O vetor é um applet Java hospedado em página web (ou entregue via link/anúncio malicioso). Basta o usuário visitar a página com o plugin Java habilitado no navegador — não há necessidade de autenticação, clique explícito no applet ou configuração fora do padrão; o carregamento automático de applets em ambientes de 2012 era o padrão de fábrica. A exploração manipula referências de campo/tipo para obter um ponteiro para uma classe privilegiada do runtime, desabilitando o SecurityManager e saindo do sandbox da JVM. A partir daí o applet roda com plenos privilégios do processo do navegador, permitindo drop e execução de payload nativo (malware, na prática, na maioria dos casos documentados). Há exploração ativa e amplamente documentada: módulo Metasploit público, PoC pública circulando, e uso massivo por kits de exploração comerciais para infecção em massa via navegador — motivo da entrada no catálogo KEV da CISA.

A correção do fornecedor está nas atualizações críticas de junho de 2012: JDK/JRE 6 Update 33 e 7 Update 5 (confirmado pela Red Hat via RHSA-2012:0734 e pelo boletim da HP, que aponta os mesmos alvos — 6.0.15+ e 7.0.02+ nas suas distribuições). Nos ramos OpenJDK/IcedTea a correção está em IcedTea6 1.10.8 e 1.11.3. Para as linhas 5 update 35 e 1.4.2_37 — listadas pela Oracle como "e anteriores" no aviso original — não há indicação nas fontes consultadas de uma versão corrigida com update público equivalente; essas linhas já estavam fora do ciclo de atualizações públicas da Oracle nessa época, então a mitigação prática ali é migrar para uma linha suportada (6u33+/7u5+), não esperar um patch retroativo.

Como paliativo quando não é possível atualizar imediatamente: desabilitar o plugin Java no navegador (ou restringir sua execução a sites explicitamente confiáveis via whitelist), que é o controle compensatório real, já que o vetor depende do plugin carregar e compilar o applet. Não existe mitigação eficaz via WAF ou filtro de rede genérico — a exploração ocorre inteiramente no lado cliente, dentro da JVM, então bloqueio de borda não impede a execução assim que o applet malicioso chega ao navegador.

Não há assinatura de rede confiável específica para esta CVE isoladamente: a exploração ocorre via bytecode Java dentro de um applet processado localmente pela JVM no navegador, sem payload de rede distintivo além do próprio download do applet/jar malicioso, que variava por kit de exploração. Na prática, a detecção histórica dependia de assinaturas de antivírus/IDS para famílias específicas de exploit kit (ex.: Blackhole) e de monitoramento de cache de applets Java (diretório de cache do plugin, arquivos .jar/.class suspeitos) e crashes anômalos do processo javaw.exe/plugin-container associados ao carregamento de páginas.