CVE-2013-2465

Falha na verificação de canais de imagem do subsistema 2D do JRE (componente afetado: java.awt.image, especificamente ImagingLib/rasters) permite que um applet ou aplicação Java não confiável escape do sandbox e execute código com os privilégios do usuário. Como o vetor típico é um applet Java carregado via navegador, a exploração é remota e não exige autenticação — daí o CVSS 10.0 (v2) atribuído por múltiplos fornecedores e a inclusão no catálogo KEV da CISA.

A causa raiz, segundo o bug interno do OpenJDK (JDK-8012597, referenciado como 'Incorrect image channel verification') e confirmado por commit público no repositório jdk7u (hg.openjdk.java.net), está na validação insuficiente dos parâmetros de canal de imagem dentro do componente 2D (pacote sun.awt.image / java.awt.image). O código de processamento de raster não verificava corretamente o número e o layout dos canais de cor de um objeto de imagem antes de operar sobre ele, permitindo que um índice ou contador de canal controlado pelo atacante levasse a acesso fora dos limites da estrutura interna de dados de imagem.

Esse tipo de falha se enquadra na família de bugs de verificação de tipo/limite (CWE-noverificado-de-entrada) que, em 2013, afetou em bloco o subsistema 2D do OpenJDK/Oracle JRE: a mesma atualização corrigiu bugs irmãos como CVE-2013-2463 (verificação de atributo de imagem), CVE-2013-2469 (verificação de layout de imagem), CVE-2013-2470/2471/2472/2473 (ImagingLib e rasters ByteBanded/ShortBanded/IntegerComponent). Todos compartilham o mesmo padrão: uma classe de imagem do AWT/2D aceita parâmetros fornecidos pelo código Java (não confiável) sem validá-los contra os limites reais do buffer nativo subjacente.

O atacante controla os parâmetros do objeto de imagem construído a partir de código Java arbitrário rodando dentro da JVM — por exemplo, dimensões, número de bandas/canais ou tipo de amostra de um Raster. Ao fornecer combinações inconsistentes, força a JVM a interpretar memória fora dos limites esperados, corrompendo estruturas internas e abrindo caminho para corrupção de memória controlada, que pesquisadores de terceiros descreveram como suficiente para contornar o Java sandbox (bypass total do modelo de permissões AccessController).

A Oracle, no aviso oficial (CPU de junho de 2013), classificou a falha apenas como 'unspecified vulnerability... related to 2D', sem detalhar o mecanismo de sandbox bypass. A afirmação de que a falha permite escape completo do sandbox via 'Incorrect image channel verification' vem de análise de terceiros (Immunity/pesquisadores independentes) — a Oracle não comentou publicamente essa caracterização específica, embora o nome do bug interno do OpenJDK confirme a localização exata do defeito.

O vetor primário é um applet Java hospedado em página web, carregado automaticamente pelo plugin Java no navegador — não exige autenticação, interação além de visitar a página (ou clicar em 'executar'), nem privilégios elevados. Isso corresponde ao vetor AV:N/AC:L/PR:N/UI:N do CVSS 3.1 atribuído (9.8) e às pontuações CVSS 2.0 de 10.0 publicadas por múltiplos fornecedores (HP, Red Hat) para este CVE. A pré-condição real é ter o plugin Java habilitado no navegador e executar aplicações/applets não confiáveis — ambientes que desabilitaram o plugin Java no browser (prática já comum após 2013 devido à onda de 0-days em Java) não são explorável por esse vetor específico, embora aplicações Java desktop que processem imagens de fontes não confiáveis também possam ser afetadas.

Esta CVE está no catálogo KEV da CISA, confirmando exploração ativa documentada, e existe módulo público no Metasploit Framework, o que reduz drasticamente a complexidade prática de exploração — não é necessário desenvolver o exploit do zero. A EPSS de 0.987 reflete probabilidade muito alta de exploração continuada, consistente com o histórico de campanhas de exploit kits (Blackhole, Cool, Neutrino e similares) que em 2013 incorporaram rapidamente múltiplos CVEs de sandbox bypass do Java, incluindo os do lote de junho de 2013 (2D component), para comprometimento massivo via drive-by download.

O resultado final da exploração bem-sucedida é execução arbitrária de código fora do sandbox, com os privilégios do usuário que executou o applet/aplicação — comprometimento total de confidencialidade, integridade e disponibilidade da máquina do usuário, consistente com o impacto C:H/I:H/A:H do CVSS.

A correção definitiva é atualizar para as versões corrigidas pela Oracle na CPU de junho de 2013: JDK/JRE 7 Update 25 ou posterior, JDK/JRE 6 Update 51 ou posterior, e JDK/JRE 5.0 Update 51 ou posterior (a versão vulnerável declarada é 7u21 e anteriores, 6u45 e anteriores, 5.0u45 e anteriores — a Oracle publicou correção no mesmo ciclo). Para distribuições baseadas em OpenJDK, aplicar os pacotes corrigidos correspondentes: Red Hat corrigiu via RHSA-2013-0957 (java-1.7.0-openjdk) e, para a linha 6, via atualização posterior que trouxe Java 6 Update 75; Mageia corrigiu com java-1.7.0-openjdk-1.7.0.25 (builds 2.3.10.1.mga2/mga3); openSUSE e HP-UX publicaram avisos equivalentes com suas próprias numerações de build.

Se a atualização não for imediatamente viável, o paliativo real é desabilitar o plugin Java no navegador (Java Applet / NPAPI plugin) ou removê-lo do sistema, já que o vetor de exploração dominante em 2013 era o applet web. Isso elimina a superfície de ataque remota sem exigir patch, mas não protege aplicações Java desktop que processem imagens de fontes não confiáveis nem elimina a vulnerabilidade em si — é mitigação de vetor, não da falha. Restringir a execução de applets via política de segurança do navegador (whitelist de sites) reduz exposição mas não é substituto de patch.

Não funciona como mitigação: manter o Java atualizado apenas no nível de 'minor patch' sem verificar o número de Update exato — como o bug foi corrigido em builds específicos por fornecedor (Oracle vs. cada distribuição Linux/HP-UX com numeração própria), é preciso confirmar a versão exata publicada pelo fornecedor usado, não assumir que 'a versão mais recente do repositório' já contém a correção.

Não há assinatura de rede confiável e específica para esta CVE isoladamente — a exploração ocorre dentro do processo da JVM (plugin de applet ou aplicação Java) e não deixa payload de rede distintivo além do download do applet/JAR malicioso, comum a dezenas de CVEs Java da mesma época. Em nível de host, sinais indiretos incluem: processos de plugin Java (java.exe, javaws, ou processo do navegador hospedando o plugin NPJP2) travando ou gerando crash dumps inesperados; carregamento de classes ou JARs de origem externa não corporativa por processos de navegador; e, em ambientes com EDR, chamadas de API incomuns originadas do runtime Java logo após navegação web. Como existe módulo Metasploit público, logs de honeypots/IDS de 2013-2014 que capturaram exploit kits (Blackhole, Cool EK) frequentemente registram o download de classes Java ofuscadas associadas a múltiplos CVEs do lote de junho de 2013 — mas atribuir tráfego especificamente a CVE-2013-2465 e não a um dos outros CVEs 2D do mesmo pacote (2463, 2469-2473) não é possível de forma confiável apenas por inspeção de tráfego.