CVE-2011-3544

Falha no componente de scripting da JRE/JDK (integração com o motor Rhino via javax.script/JSR 223) que permite a um applet Java ou aplicação Java Web Start não confiável escapar da sandbox e executar código arbitrário com os privilégios do usuário local. É uma das CVEs Java mais exploradas da história: virou módulo padrão de kits de exploração (Blackhole, Nuclear) entre 2012 e 2013 e está no catálogo KEV da CISA por exploração ativa confirmada.

O bug (CWE relacionado a controle de acesso ausente, mapeado internamente pela Oracle/OpenJDK como bug 7046823) está na forma como a JRE expõe o motor de scripting Rhino embutido a código não confiável. O componente de scripting não aplicava corretamente as checagens do SecurityManager antes de permitir que um applet ou aplicação Web Start invocasse funcionalidade do motor JavaScript interno da JVM.

Como o SecurityManager é o mecanismo que separa código 'sandboxed' (applet/Web Start não assinado) de código com privilégios totais, a ausência dessa checagem no caminho de scripting permite que o atacante alcance classes e métodos que deveriam estar fora do alcance de um applet — em particular, rotas que permitem desabilitar o próprio SecurityManager ou obter uma referência a um ClassLoader privilegiado.

O atacante não precisa controlar parâmetros de rede, autenticação ou configuração específica do JRE: o vetor é o próprio applet/JNLP malicioso, hospedado numa página web ou entregue como anexo. O único pré-requisito técnico é que a vítima tenha um JRE vulnerável instalado e habilitado no navegador (plugin Java) ou associado a arquivos .jnlp.

A confidencialidade, integridade e disponibilidade completas do CVSS (C:H/I:H/A:H) refletem que, uma vez fora da sandbox, o código roda com os privilégios do processo Java do usuário — equivalente a execução de código arbitrário local, sem elevação adicional necessária na maioria dos casos.

A exploração real ocorre via drive-by download: a vítima visita uma página com um applet malicioso (ou abre um arquivo JNLP) servido por um Java Web Start ou embutido via /. O navegador invoca o plugin Java, que carrega e executa o applet não confiável; o applet então aciona o caminho de scripting vulnerável para escapar da sandbox e executar código nativo — instalação de malware, backdoor, etc. Não há necessidade de autenticação, interação complexa da vítima (alguns cliques de 'permitir aplicativo' podem ou não aparecer dependendo da configuração de segurança do plugin) ou acesso à rede interna: é ataque remoto clássico contra cliente.

Esta CVE ficou conhecida por ser a base do módulo Metasploit 'java_rhino' (Java RHINO Script Engine Remote Code Execution) e por ter sido incorporada rapidamente aos principais exploit kits comerciais da época (Blackhole, Nuclear, entre outros), que a usavam como um dos vetores mais confiáveis de comprometimento massivo de máquinas Windows com Java desatualizado — daí a presença no catálogo KEV da CISA como exploração confirmada in-the-wild.

A complexidade de exploração é baixa: o exploit não depende de layout de memória, ASLR/DEP bypass ou heap grooming — é abuso lógico de checagem de permissão ausente, o que o torna extremamente confiável e portátil entre versões vulneráveis (6u27 e anteriores, e as builds afetadas do JDK 7).

A correção definitiva é atualizar para uma versão do Java SE lançada no Critical Patch Update de outubro de 2011 da Oracle, que corrigiu este e outros defeitos do mesmo lote de scripting/2D/AWT/RMI listados nos boletins de terceiros (HP, Red Hat) — atualize para a versão de JDK/JRE 6 e 7 recomendada pelo fornecedor da sua distribuição Java na época (Oracle, OpenJDK ou IBM JDK, conforme o caso), pois cada um empacotou o fix em builds próprias e numeradas diferentemente.

Se não for possível atualizar imediatamente, o paliativo real é desabilitar ou desinstalar o plugin Java do navegador (Java Deployment Toolkit / Java plugin) e desassociar arquivos .jnlp da execução automática via Java Web Start — isso elimina o vetor de entrega, já que o applet/Web Start nunca chega a rodar. Definir o nível de segurança do Java Control Panel para 'High' ou exigir assinatura/confirmação explícita reduz superfície mas não corrige a falha de checagem em si — não é mitigação confiável contra um applet que já tenha permissão de execução.

O que NÃO funciona: manter o Java instalado apenas 'atualizado no sistema' sem desabilitar o plugin do navegador não protege, pois o vetor primário é o navegador carregando o applet automaticamente; e confiar em antivírus de endpoint para bloquear os exploit kits que empacotavam este CVE mostrou-se historicamente insuficiente, dado o volume e a variação constante de payloads observados nas campanhas Blackhole/Nuclear.

Não há assinatura de rede confiável e específica para esta falha isolada: a exploração ocorre inteiramente dentro do processo Java do cliente após o carregamento do applet/JNLP, sem payload de rede distintivo além do download HTTP do próprio applet malicioso. Em ambientes com telemetria de endpoint, o indicador mais útil é um processo java.exe/javaw.exe gerando processos filhos inesperados (cmd.exe, powershell.exe, downloads de executáveis) imediatamente após acesso a uma página web ou abertura de um .jnlp — padrão comum às campanhas de exploit kit que usaram este CVE em 2012-2013. Logs de proxy/IDS podem mostrar requisições a arquivos .jar ou .jnlp hospedados em domínios associados a exploit kits daquele período, mas isso é evidência indireta, não prova de exploração deste CVE específico.