CVE-2015-2590

Falha de deserialização insegura no componente Libraries do Java SE (java.io.ObjectInputStream.readSerialData()), que permite a uma aplicação Java não confiável — tipicamente um applet ou aplicação Java Web Start carregada de origem remota — escapar do sandbox e comprometer totalmente a JVM. Está no catálogo KEV da CISA, ou seja, há confirmação de exploração ativa; isso pesa mais do que o CVSS 9.8 isolado, porque o vetor real depende do usuário rodar código Java não assinado/não confiável, não de um serviço de rede exposto.

A vulnerabilidade fica no processo de desserialização de objetos do Libraries do OpenJDK/Oracle JDK, especificamente no método readSerialData() de ObjectInputStream, identificado internamente pela Oracle/OpenJDK como bug 8076401. A Oracle não publicou detalhes técnicos da causa raiz (é uma "unspecified vulnerability", como quase todas as CVEs do Java CPU dessa era), mas o padrão de bugs vizinhos no mesmo Critical Patch Update de julho de 2015 — CVE-2015-4732 ("insufficient context checks during object deserialization", também em Libraries) — indica que a classe do problema é checagem de contexto/permissão insuficiente durante a reconstrução de objetos a partir de um stream serializado, o que se encaixa em CWE-502 (Deserialization of Untrusted Data).

A CVE-2015-2590 é explicitamente descrita pela Oracle como uma falha distinta de CVE-2015-4732, embora ambas estejam no mesmo subsistema e no mesmo boletim. Isso sugere dois caminhos separados de exploração dentro do código de desserialização, não a mesma linha de código.

O atacante controla o conteúdo do stream serializado que é entregue à JVM da vítima — normalmente via um applet, aplicativo Java Web Start ou biblioteca carregada por uma aplicação Java que aceita objetos serializados de origem não confiável. Ao manipular esse stream, a falha de checagem permite que código rodando fora dos limites do sandbox padrão do Java (SecurityManager) obtenha privilégios que deveria ter negados, viabilizando execução de operações normalmente restritas — leitura/escrita de arquivos, execução de processos, acesso à rede — de dentro do processo Java da vítima.

O vetor prático historicamente associado a esse tipo de CVE do Java é o applet malicioso servido por um site comprometido ou controlado pelo atacante, ou uma aplicação Java Web Start assinada de forma a passar por controles superficiais. A vítima só precisa visitar uma página com o applet ou executar o artefato Java — não há necessidade de autenticação, e a interação do usuário pode ser mínima (carregar a página com o plugin do navegador habilitado), o que justifica AV:N/PR:N/UI:N no vetor CVSS.

O pré-requisito real, que a nota do CVSS 9.8 não deixa claro, é que a vítima precisa ter um Java Runtime vulnerável ativo no navegador (plugin Java) ou executar deliberadamente uma aplicação/applet Java não confiável que aceite objetos serializados de origem externa. Em servidores e ambientes sem plugin de navegador Java habilitado e sem processamento de streams serializados de fontes não confiáveis, a superfície de ataque prática é bem menor do que a pontuação sugere.

O resultado de uma exploração bem-sucedida é o escape do Java sandbox: o código do atacante passa a rodar com privilégios equivalentes aos da aplicação Java local, permitindo leitura de arquivos, execução de código nativo, persistência e pivotagem — coerente com o impacto C:H/I:H/A:H do vetor. A presença no catálogo KEV da CISA confirma exploração observada em campo, típica do período em que kits de exploração (drive-by, distribuídos via propagandas maliciosas ou sites comprometidos) miravam plugins Java desatualizados em massa; as fontes consultadas não detalham qual campanha específica usou esta CVE em particular.

A correção oficial veio no Oracle Critical Patch Update de julho de 2015. Para a linha Oracle JDK/JRE 8, a Red Hat confirma que o pacote java-1.8.0-oracle corrigido corresponde ao Oracle Java 8 Update 51 (RHSA-2015:1241). Para OpenJDK, a correção foi distribuída via RHSA-2015:1228 (java-1.8.0-openjdk, RHEL 6/7), RHSA-2015:1229 (java-1.7.0-openjdk, RHEL 6/7) e RHSA-2015:1230 (java-1.7.0-openjdk, RHEL 5), todas de 15/07/2015 — atualize para os pacotes dessas errata ou builds equivalentes mais recentes do OpenJDK 7/8. Após a atualização, é obrigatório reiniciar todas as instâncias em execução da JVM, já que o processo antigo continua vulnerável em memória.

Se a atualização imediata não for viável, o único controle compensatório real é reduzir a superfície de ataque: desabilitar ou remover o plugin Java do navegador (principal vetor de applets maliciosos), restringir a execução de Java Web Start a fontes assinadas e confiáveis, e bloquear em firewall/proxy o carregamento de conteúdo Java de origens não confiáveis. Isso não corrige a falha, apenas reduz a chance de entrega do vetor.

Não funciona como mitigação apenas desabilitar RC4 ou ajustar parâmetros de TLS — essas mudanças, presentes no mesmo conjunto de patches (CVE-2015-2808, CVE-2015-4000), tratam de problemas de criptografia de canal, não da falha de desserialização em si. Também não há flag de configuração da JVM documentada que neutralize especificamente CVE-2015-2590; a correção é apenas via atualização de versão.

Não há assinatura de rede confiável para detectar exploração dessa falha especificamente, porque o payload é um stream serializado Java entregue dentro de um applet/aplicação — sem padrão de protocolo distinto de tráfego Java legítimo. Em ambientes corporativos, sinais indiretos úteis são: execução do plugin Java do navegador acessando domínios externos incomuns, processos java.exe/javaw filhos de navegadores gerando conexões de rede ou gravações em disco fora do padrão, e logs de segurança do Java (se habilitados) registrando exceções de SecurityManager durante a carga de applets. Nenhuma dessas evidências é exclusiva desta CVE; a ausência de detecção confiável e específica é, em si, o dado relevante para quem investiga incidentes anteriores a 2015 envolvendo Java.