CVE-2010-0840

Falha no Java Runtime Environment (Oracle Java SE / Java for Business) que permite a um applet Java malicioso escapar do sandbox de segurança e executar código arbitrário no contexto do usuário, sem autenticação e sem interação além de carregar uma página web. Ficou conhecida como 'Trusted Methods Chaining' e foi amplamente incorporada a kits de exploração automatizados no início dos anos 2010, o que justifica sua presença no catálogo KEV da CISA muito tempo depois da divulgação original.

O mecanismo de segurança do JRE (SecurityManager) controla a execução de métodos privilegiados fazendo 'stack walking': para cada chamada a um método que exige privilégio, o runtime percorre a pilha de chamadas e verifica se cada frame pertence a uma classe que possui aquele privilégio. O problema (CWE-863, controle de acesso incorreto) é que essa verificação não trata corretamente o caso em que uma classe não confiável estende uma classe confiável sem sobrescrever o método-alvo: a verificação de pilha encontra a classe pai (confiável) e concede o privilégio, mesmo a invocação originando de código não confiável carregado, por exemplo, via applet. Sami Koivu, pesquisador que reportou a falha via ZDI, descreveu um problema equivalente envolvendo interfaces ('a similar trust issue with interfaces'), abrindo uma segunda via de bypass.

O atacante controla o bytecode do applet/objeto Java malicioso: ele constrói uma hierarquia de classes que abusa dessa lacuna de verificação para encadear chamadas ('trusted methods chaining') até atingir uma API privilegiada da JVM — normalmente algo equivalente a desabilitar o SecurityManager ou obter acesso irrestrito ao sistema de arquivos/processos do host, o que na prática equivale a fugir completamente do sandbox de applets.

A descrição oficial da Oracle no NVD é deliberadamente genérica ('unspecified vulnerability'); o vetor técnico específico só é conhecido porque o pesquisador (Sami Koivu, via ZDI-10-056) publicou a análise, não porque a Oracle confirmou o mecanismo publicamente.

Vetor client-side: uma página web hospeda um applet Java malicioso; a vítima só precisa carregá-la com o plugin Java habilitado no navegador para o exploit rodar — não há necessidade de autenticação, e a interação exigida do usuário é mínima (nas configurações de segurança da época, muitos ambientes executavam applets não assinados sem prompt explícito). A ZDI classificou a exploração como de baixa complexidade e sem necessidade de autenticação (AV:N/AC:L/Au:N).

A falha teve PoC pública e módulo Metasploit, e o padrão de exploração (escape de sandbox Java via applet) foi amplamente absorvido por kits de exploração automatizados de infecção drive-by no início dos anos 2010, o que explica sua listagem no catálogo KEV da CISA muito depois de 2010: o registro reflete evidência de exploração ativa continuada, não um ataque pontual isolado.

O resultado final de exploração bem-sucedida é execução de código arbitrário fora do sandbox do applet, no contexto do usuário que executa a JVM — comprometimento completo da estação de trabalho a partir de uma visita a página maliciosa, sem qualquer pré-condição de configuração exótica além de ter o plugin Java ativo no navegador.

A correção definitiva é atualizar o JRE/JDK para além das versões listadas como vulneráveis pela Oracle (6 Update 18, 5.0 Update 23 e 1.4.2_25, conforme o CPU de março de 2010). As fontes consultadas confirmam builds corrigidas por fornecedores que redistribuem JRE em datas posteriores: a HP, em bulletin de junho de 2010, lista como corrigidas as versões HP-UX JDK/JRE 6.0.07, 5.0.20 e SDK/JRE 1.4.2.25 (numeração de build própria da HP, não necessariamente idêntica à nomenclatura 'Update' da Oracle); Apple e openSUSE também publicaram atualizações de segurança para seus pacotes Java entre abril e setembro de 2010. Não há, nas fontes consultadas, confirmação explícita do número de 'Update' Oracle upstream que introduziu a correção — qualquer versão anterior a essas atualizações de maio/junho de 2010 deve ser tratada como vulnerável.

Se a atualização não for viável de imediato, o controle compensatório real é desabilitar ou desinstalar o plugin Java do navegador (ou bloquear a execução de applets/Java Web Start), já que o vetor primário é drive-by via applet em página web — isso neutraliza a exploração remota sem depender de patch, ao custo de quebrar qualquer aplicação legítima que dependa de applets.

Manter apenas antivírus atualizado ou confiar no sandbox padrão do navegador não mitiga a falha: o próprio mecanismo de sandboxing do SecurityManager é o que está sendo contornado pelo exploit, então soluções que assumem que o sandbox funciona não detectam nem bloqueiam o ataque.

Não há assinatura de rede única e confiável: o exploit é entregue como bytecode Java (classe/applet), frequentemente ofuscado e variando por kit de exploração, dentro de payloads HTTP legítimos de arquivos .jar/.class. Em logs de proxy web, procurar downloads de .jar/.class hospedados em domínios recém-registrados ou incomuns seguidos de tráfego de saída atípico originado do host. Em endpoint, o indicador mais confiável é comportamental: o processo java.exe/javaw.exe gerando processos filhos inesperados (interpretadores de comando, downloaders, binários desconhecidos) pouco depois de uma sessão de navegação — padrão característico de exploração bem-sucedida de exploits Java client-side da era dos kits de exploração automatizados.