CVE-2013-2423

Falha no componente HotSpot do JRE (Oracle Java SE 7 Update 17 e anteriores, e OpenJDK 7) que permite a uma aplicação Java não confiável — um applet ou aplicação executada dentro da sandbox — burlar as verificações de acesso do java.lang.invoke.MethodHandles e sobrescrever campos declarados como 'final'. Na prática isso quebra o modelo de segurança da JVM: o pesquisador original demonstrou que a falha permite desativar o próprio SecurityManager, ou seja, sair completamente da sandbox. Foi amplamente explorada por kits de exploração via applets Java maliciosos entre 2013 e anos seguintes, o que a colocou no catálogo KEV da CISA.

O bug (rastreado internamente pela Oracle/OpenJDK como JDK-8009677) está na forma como HotSpot resolve e aplica checagens de acesso em MethodHandles usados por setters de campos. A implementação não validava corretamente se o código chamador tinha permissão para modificar um campo 'final' antes de expor o handle de escrita, e não tratava adequadamente o tipo declarado do campo em relação ao tipo real manipulado via reflection — uma condição de type confusion (CWE-843) somada a controle de acesso incorreto (CWE-284/CWE-863).

O atacante controla o código Java executado dentro da sandbox (um applet, por exemplo) e, através dele, escolhe qual campo final atacar e qual MethodHandle solicitar. O pesquisador que reportou a falha (a descrição do NVD se refere a ele como 'original researcher', sem nome creditado pela Oracle) demonstrou a técnica usando campos do tipo int e double, aproveitando a confusão de tipo para escrever um valor arbitrário em um campo final que deveria ser imutável.

O efeito prático relevante é escrever em campos internos da própria JVM ou de classes do runtime que controlam políticas de segurança. Ao modificar o campo correto (por exemplo, um flag interno do gerenciador de segurança), o código sandboxed consegue desativar as próprias restrições impostas pelo SecurityManager, deixando de operar dentro dos limites do sandbox.

A Oracle classificou oficialmente o vetor apenas como 'unspecified' relacionado a HotSpot, sem detalhar o mecanismo de MethodHandles — essa é a informação que vem apenas da análise do pesquisador original e de terceiros (como SpiderLabs), não confirmada em texto pela Oracle.

O vetor de rede exigido no CVSS (AV:N) reflete o cenário clássico de 2013: uma vítima acessa uma página web com um applet Java malicioso, ou executa uma aplicação Java Web Start não confiável, e o plugin/runtime Java carrega esse código automaticamente dentro da sandbox. Não é necessária autenticação nem configuração não padrão — o pré-requisito real é ter o plugin Java habilitado no navegador ou executar conteúdo Java não confiável de alguma forma, o que em 2013 era comum em ambientes corporativos e desktops.

A complexidade de ataque é classificada como alta (AC:H) porque a exploração depende da técnica específica de type confusion com MethodHandles — não é uma falha trivial de acionar, exige conhecimento detalhado da API de invocação dinâmica do Java e de quais campos internos sobrescrever para desabilitar o SecurityManager. Uma vez dominada a técnica, o resultado final é fuga completa da sandbox: o código do atacante passa a rodar com os privilégios do processo Java, permitindo execução arbitrária de código no contexto do usuário que executou o applet.

Essa CVE foi amplamente incorporada a kits de exploração automatizados (o tipo de ataque drive-by que dominou o cenário de exploração de Java entre 2012 e 2013), o que justifica sua presença no catálogo KEV da CISA e a existência de módulo Metasploit e PoC pública. O padrão de exploração observado não exigia interação além de a vítima visitar uma página com o applet incorporado.

A correção definitiva é atualizar para Oracle Java SE 7 Update 21 ou posterior; para distribuições baseadas em OpenJDK 7, atualizar para IcedTea 2.3.9 ou posterior (pacotes java-1.7.0-openjdk corrigidos via RHSA-2013:0751/0752, e java-1.7.0-oracle via RHSA-2013:0757, que entrega o equivalente ao 7u21). O commit upstream que corrige o problema está no repositório jdk7u-dev (revisão b453d9be6b3f).

Como paliativo, na ausência de atualização imediata, a mitigação real é desabilitar ou remover o plugin Java do navegador e restringir a execução de applets/Java Web Start não confiáveis — isso elimina o vetor de entrega mais comum, mas tem custo funcional para aplicações internas que ainda dependam de applets. Não existe flag de configuração da JVM documentada que neutralize especificamente essa falha sem a atualização; políticas de sandbox mais restritivas no navegador reduzem exposição mas não corrigem a vulnerabilidade subjacente em MethodHandles.

Não funciona como mitigação apenas desativar o SecurityManager por padrão ou confiar em listas de bloqueio de applets sem também restringir a execução do plugin — o próprio bug existe para burlar exatamente esse mecanismo de proteção.

Não há assinatura de rede confiável e específica para essa CVE isoladamente: a exploração ocorre dentro do processo Java local após o download de um applet/classe malicioso, então o sinal mais útil é no host, não no tráfego. Procure por processos java.exe/javaw ou pelo plugin do navegador carregando classes de origens externas incomuns, seguidos de comportamento anômalo do processo (spawning de shells, escrita em disco fora de diretórios esperados) — padrão típico de exploração via drive-by de kits de exploração Java da época. Logs de proxy/EDR que registrem download de arquivos .jar ou .class de domínios suspeitos, correlacionados com crashes ou reinícios do runtime Java, são indicadores indiretos; não há um IOC de rede único documentado para CVE-2013-2423 especificamente.