Descoberta e escopo da vulnerabilidade
Uma questão recém-divulgada do Apache Log4j2 pode permitir que atacantes contornem uma lista de permissões de desserialização e executem código remotamente em implantações estritamente definidas. A questão, rastreada como Log4j2 #4255, afeta aplicativos que aceitam eventos Log4j serializados através de um caminho de desserialização Java acessível pela rede.
A fraqueza relatada envolve o FilteredObjectInputStream do Log4j, uma utilidade projetada para restringir quais classes Java podem ser carregadas enquanto leem eventos de log serializados. Sua lista de permissões inclui Java.rmi.MarshalledObject, um contêiner Java que pode armazenar outro objeto serializado como uma matriz de bytes opaca. Pesquisadores descobriram que este objeto externo pode passar pela lista de permissões do Log4j enquanto oculta um objeto interno malicioso.
Quando o Log4j chama posteriormente MarshalledObject.get(), a desserialização Java do payload incorporado usa um ObjectInputStream fresco e não filtrado. Isso significa que a lista de permissões original não inspeciona o gráfico de objetos oculto. O fluxo vulnerável está ligado ao Log4jLogEvent$LogEventProxy, a representação serializada de um evento Log4j.
Impacto e alcance
Um atacante poderia criar um evento Log4j serializado malicioso, enviá-lo a um receptor vulnerável e causar uma cadeia de gadgets disponível no classpath do alvo para executar. O laboratório de reprodução pública demonstrou a questão no Log4j 2.26.1 executando no JDK 17. No ambiente de teste, um payload malicioso incorporado em um MarshalledObject acionou execução de código quando processado por um receptor TCP não autenticado usando FilteredObjectInputStream.
Porém, a questão não é comparável à vulnerabilidade Log4Shell generalizada. Ela não pode ser acionada simplesmente colocando uma string maliciosa em uma mensagem de log de aplicativo. A exploração requer uma configuração específica e incomum: um aplicativo deve expor um receptor que aceita eventos Log4j serializados controlados pelo atacante, processá-los usando FilteredObjectInputStream e incluir uma cadeia utilizável de gadgets de desserialização Java.
O código de produção atual do Log4j Core normalmente não desserializa dados recebidos de sockets, filas ou outras fontes externas. O projeto descreve o FilteredObjectInputStream como uma utilidade de defesa em profundidade, em vez de uma fronteira de segurança completa.
Medidas de mitigação recomendadas
Organizações devem identificar receptores de eventos Log4j serializados legados, especialmente serviços de rede não autenticados baseados em padrões antigos de ponte de soquete. Uma mitigação temporária é configurar o filtro de desserialização JVM para rejeitar Java.rmi.MarshalledObject, embora isso também possa bloquear eventos Log4j serializados legítimos.
Defesas mais duráveis incluem remover a serialização Java do transporte de log, atualizar ou remover dependências de gadgets vulneráveis, usar endpoints mutuamente autenticados e migrar para log JSON ou RFC 5424 sobre TLS. O Apache recomenda especificamente formatos estruturados e TLS em vez de transporte de log serializado Java.
O que os CISOs devem fazer imediatamente
A falha é melhor entendida como um bypass perigoso de desserialização em receptores de eventos Log4j legados ou personalizados, não como uma falha universal de execução remota de código que afeta implantações comuns de Log4j. Monitorar serviços de log expostos e revisar configurações de desserialização é essencial. Considerar a migração para formatos de log não serializados reduzirá a superfície de ataque a longo prazo.