Resumo

O FilteredObjectInputStream (FOIS) do Log4j é uma allowlist de desserialização baseada em resolveClass. Sua allowlist inclui java.rmi.MarshalledObject. Um MarshalledObject armazena seu payload como um byte[] opaco, e MarshalledObject.get() desserializa esse payload em um ObjectInputStream novo e sem filtro — portanto, a allowlist nunca inspeciona o grafo interno.

O próprio Log4j aciona isso: Log4jLogEvent$LogEventProxy (a forma serializada em fio de um LogEvent, desde a versão 2.8) carrega o Message do evento dentro de um MarshalledObject e chama .get() automaticamente durante a desserialização (readResolve() → message()). Qualquer aplicação que leia um LogEvent serializado por meio do FOIS realiza, portanto, desserialização sem filtro de bytes do atacante — e como message() engole a exceção resultante e recai para SimpleMessage, o receptor registra um evento benigno e continua em execução. O exploit é silencioso.

Causa raiz (verificada em rel/2.26.1)

O que o laboratório executa

Um substituto fiel do descontinuado ObjectInputStreamLogEventBridge do log4j-samples: um receptor TCP não autenticado que lê um LogEvent serializado por conexão por meio do FOIS. O atacante envia um único objeto serializado; o oráculo é um arquivo de prova gravado em um diretório montado por bind apenas no contêiner do receptor, de modo que seu aparecimento prova que o código foi executado dentro do receptor via desserialização.

rce = código executado. rejeitar = o FOIS lançou exceção no fluxo externo. silencioso = objeto externo processado, nenhum código executado (bloqueado mais profundamente, ou a versão do gadget é segura).

Como executar

Requisitos: apenas Docker (um JDK é baixado como eclipse-temurin:17-jdk). O script baixa os jars oficiais e os verifica contra o SHA-1 do Maven Central antes do uso. Fixe uma versão diferente do Log4j na faixa vulnerável com LOG4J_VERSION=2.20.0 ./run.sh.

Impacto e método de ataque

• Entrega: uma única gravação TCP não autenticada de ~2,8 KB de um LogEvent serializado para um receptor baseado em FOIS. Não é acionável ao fazer com que uma string seja registrada (diferente do Log4Shell) — é necessário que bytes serializados brutos cheguem à ponte de soquete.
• Resultado: execução arbitrária de comandos no processo do receptor, silenciosamente.
• Caminho do ataque: construir um LogEvent → o writeReplace()/writeObject() do Log4j envolve o Message em um MarshalledObject → o gadget se esconde dentro de seu byte[] opaco → no receptor, readResolve() → message() → MarshalledObject.get() abre um fluxo novo sem filtro → gadget → Runtime.exec. src/attacker/Attacker.java (poc2) insere um grafo puro de CommonsCollections6 no objBytes do MarshalledObject, portanto nenhuma classe do atacante é necessária na vítima.

Mitigação

• Confiável: -Djdk.serialFilter='!java.rmi.MarshalledObject' na JVM do receptor (S5). Ressalva: isso também bloqueia objetos legítimos de LogEventProxy serializados (eles usam MarshalledObject também) — é eficaz, mas não é transparente para o transporte de logs serializados.
• Não confiável: filtros genéricos de maxdepth/maxbytes. O filtro de todo o processo se propaga para o fluxo interno do MarshalledObject e a profundidade recomeça ali, portanto maxdepth=5 bloqueia CC6 (S6), mas um gadget raso passaria. Depende da profundidade da cadeia, não é um limite.
• Estrutural: elimine o transporte de logs serializados em Java (use JSON / RFC 5424 sobre TLS autenticado); remova dependências de gadgets conhecidos; não exponha receptores serializados legados a redes não confiáveis. Correção a montante (conforme o problema): remover MarshalledObject da allowlist e mover a mensagem serializada para os writeWrappedObject/readWrappedObject filtrados do Log4j.

Escopo e limitações honestas

• Condicional à aplicação, não um RCE geral do Log4j. Requer um aplicativo que exponha um receptor de LogEvent serializado não autenticado baseado em FOIS e tenha uma versão de gadget utilizável em seu classpath. Implantações comuns do Log4j não executam tal receptor.
• O servidor de soquete serializado no núcleo existiu apenas até a 2.8.2 (net.server.TcpSocketServer foi movido para fora do log4j-core em 2017; ausente desde a 2.9.0). Receptores modernos são código de aplicação/exemplo, que este laboratório modela.
• Depende da versão do gadget. commons-collections 3.2.1 → RCE; 3.2.2 o bloqueia (S7). Qualquer gadget utilizável é suficiente, mas "ter commons-collections" por si só não é suficiente.
• uid=0 no laboratório é root do contêiner — não há escape do Docker; o RCE é executado como o processo do receptor.
• A primitiva (MarshalledObject derrotando um filtro resolveClass) é arte anterior conhecida; consulte a discussão do Apache #4168 ("Endurecimento de desserialização do Log4j 2.x"). O acionamento automático específico do Log4j é a contribuição do #4255.

Estrutura

Referências

• Problema #4255 — https://github.com/apache/logging-log4j2/issues/4255
• Discussão #4168 (endurecimento de desserialização) — https://github.com/apache/logging-log4j2/discussions/4168
• FAQ do Log4j sobre CWE-502 — https://logging.apache.org/security/faq.html
• Aviso de segurança do Apache Commons Collections — https://commons.apache.org/proper/commons-collections/security.html

Créditos

Vulnerabilidade relatada por U-Sec (Wujie Security) no Apache log4j2 #4255. Este repositório é um laboratório independente de reprodução/validação para pesquisa defensiva e engenharia de detecção.