CVE-2016-8735

Falha de deserialização remota no listener opcional JmxRemoteLifecycleListener do Apache Tomcat, usado para expor JMX via RMI com autenticação/SSL. O Tomcat não replicou a correção que a Oracle aplicou em CVE-2016-3427, deixando a troca de credenciais JMX vulnerável ao mesmo vetor de RCE. O próprio time do Tomcat classificou como 'Important', não crítico, porque o listener não é padrão e expor a porta JMX à rede é configuração rara — o CVSS 9.8 supõe esse cenário incomum como se fosse trivial.

O JmxRemoteLifecycleListener é um componente opcional do Tomcat (não habilitado por padrão) que configura um conector JMX RMI com autenticação e, opcionalmente, SSL, para permitir monitoramento remoto da JVM. A Oracle corrigiu em 2016, via CVE-2016-3427, uma falha no mecanismo de troca de credenciais do JMX RMI Connector Server que permitia deserialização de objetos arbitrários antes da autenticação ser validada. O Tomcat mantinha sua própria implementação desse listener e não incorporou o ajuste equivalente, então o mesmo padrão de deserialização insegura (CWE-502) permanecia explorável em quem usasse o listener do Tomcat em vez do padrão puro da JVM.

Pré-requisito determinante: a instância precisa ter o JmxRemoteLifecycleListener configurado explicitamente em server.xml — não é comportamento padrão de nenhuma instalação Tomcat — e a porta RMI/JMX resultante precisa estar acessível pela rede ao atacante. Com essas duas condições satisfeitas, o atacante se conecta à porta JMX e explora a deserialização durante a negociação de credenciais, sem precisar de credencial válida, obtendo execução de código no contexto do processo Tomcat/JVM.

A Apache Foundation e a Red Hat descrevem o cenário como raro: poucas instalações usam esse listener, e é 'altamente incomum' que a porta JMX fique exposta a um atacante, mesmo quando o listener está ativo. Isso contradiz a leitura direta do CVSS 9.8 (que assume rede acessível por padrão) — o vetor exige uma configuração de monitoramento avançado que a maioria dos ambientes de produção não expõe externamente.

Existe PoC pública e a CVE está no catálogo KEV da CISA, confirmando exploração real, mas isso reforça o risco para o subconjunto de organizações que efetivamente usam JMX remoto sobre RMI com este listener, não para toda instalação Tomcat.

Solução definitiva é atualizar para Tomcat 6.0.48+, 7.0.73+, 8.0.39+, 8.5.8+ ou 9.0.0.M13+ (o mail da Apache observa que 8.5.7 e 9.0.0.M12 continham a correção mas não chegaram a ser lançados como binários — a recomendação prática é ir para 8.5.8 e 9.0.0.M13). Distribuições derivadas, como JBoss Web Server 3.1.0 (RHSA-2017:0455/0456/0457), empacotaram o mesmo fix.

Se a atualização não for viável de imediato, o paliativo real é: remover ou desabilitar o JmxRemoteLifecycleListener em server.xml caso não seja estritamente necessário, ou, se for necessário, restringir o acesso à porta JMX/RMI via firewall/segmentação de rede a apenas hosts de monitoramento confiáveis — isso neutraliza o pré-requisito de alcançabilidade que a falha exige.

Não adianta tratar isso como problema de aplicação web: a falha está na camada JMX/RMI, fora do pipeline HTTP, então WAF ou hardening de servlet não mitigam. A mitigação de rede (bloquear a porta) é eficaz e de baixo custo justamente porque o vetor de ataque depende inteiramente de conectividade de rede à porta JMX.

Não há assinatura confiável em log de acesso HTTP do Tomcat, porque o vetor passa pela camada JMX/RMI, fora do pipeline de requisições web. O sinal a procurar é tráfego de rede em direção à porta configurada para o JmxRemoteLifecycleListener (porta custom, definida em server.xml, distinta das portas HTTP/AJP padrão) originado de IPs não pertencentes à infraestrutura de monitoramento legítima, e conexões RMI seguidas de payloads de deserialização anômalos. Auditar server.xml em busca do listener configurado é o primeiro passo para saber se o ambiente sequer está exposto a este vetor.