CVE-2012-5076

Falha na Java Runtime Environment (JRE) da Oracle relacionada ao componente JAX-WS: a configuração padrão de propriedades de segurança do Java não restringia o acesso a pacotes internos com.sun.org.glassfish.*, permitindo que uma aplicação ou applet Java não confiável escape do sandbox. Importa porque, em 2012, applets Java em navegador eram vetor comum de infecção via drive-by download — um bypass de sandbox aqui equivale a execução de código com privilégios totais fora da caixa de restrições do Java, sem exigir autenticação nem interação sofisticada do usuário além de carregar o applet malicioso.

A causa raiz, confirmada pelos advisories de OpenJDK (bug interno JAX-WS, rastreado como BZ 865352 na Red Hat), é a ausência de restrição de acesso a determinados pacotes internos do Metro/JAX-WS (com.sun.org.glassfish.*) na lista de pacotes restritos da JVM. O modelo de sandbox do Java depende de uma lista de pacotes 'package.access' e 'package.definition' que o SecurityManager usa para impedir que código não confiável instancie ou chame classes privilegiadas do runtime. Como esses pacotes glassfish não estavam nessa lista, uma aplicação Java untrusted conseguia alcançá-los e, a partir daí, escalar para operações fora do sandbox — o CWE mais próximo é CWE-284 (Improper Access Control) combinado com um bypass de sandbox (CWE-693, Protection Mechanism Failure).

O vetor é client-side: a vítima precisa executar código Java não confiável, tipicamente um applet embutido em uma página web (via plugin Java no navegador) ou uma aplicação Java Web Start, sem qualquer autenticação exigida. O atacante controla o próprio applet/JAR malicioso, que explora a ausência de restrição nos pacotes glassfish para escapar do SecurityManager e obter as mesmas permissões que código local confiável — o que na prática significa execução arbitrária de código no contexto do usuário que roda a JVM, com leitura/escrita de arquivos e acesso à rede. A CVE está no catálogo KEV da CISA (exploração confirmada em campo) e possui módulo Metasploit e PoC pública, o que reduz bastante a complexidade prática: o exploit era empacotável em kits de exploração de navegador da época, dispensando qualquer engenharia social além de convencer a vítima a visitar uma página com o plugin Java habilitado.

A correção oficial veio no Oracle Java SE 7 Update 9 (Critical Patch Update de outubro de 2012) e nos backports de OpenJDK 7 (IcedTea7 2.3.3) distribuídos por Red Hat (RHSA-2012:1386 para java-1.7.0-openjdk, RHSA-2012:1391 para java-1.7.0-oracle) e IBM (RHSA-2012:1467, IBM Java SE 7 SR3). Atualizar para essas versões corrige o problema ao adicionar os pacotes com.sun.org.glassfish.* à lista de pacotes restritos por padrão. Onde não for possível atualizar imediatamente, o controle compensatório mais eficaz é desabilitar ou remover o plugin Java do navegador e restringir a execução de Java Web Start via política — não existe flag de configuração pontual documentada pelo fornecedor que mitigue essa falha sem atualizar o JRE, já que o problema está na lista de restrição padrão do runtime. Manter apenas um antivírus ou WAF não mitiga: o ataque ocorre no lado do cliente, dentro da JVM local, fora do alcance de controles de borda de rede.

Não há assinatura de rede confiável, pois a exploração ocorre dentro do processo da JVM local, não em tráfego de rede distintivo. Em endpoints, sinais indiretos incluem o carregamento de classes JAR/applet incomuns via javaw.exe/java.exe a partir de diretórios temporários do navegador, logs do Java Deployment/Plugin registrando exceções de SecurityManager relacionadas a pacotes com.sun.org.glassfish, e presença de módulos de exploit kit conhecidos da época (2012-2013) em cache de navegador. Como a falha é antiga e o módulo Metasploit é público, qualquer scanner de vulnerabilidades que identifique a versão exata do JRE/JDK instalado (7u7 ou anterior) é o indicador mais confiável de exposição — não há como distinguir tentativa de exploração de uso legítimo apenas pelo tráfego HTTP.