TL;DR

Le FilteredObjectInputStream (FOIS) de Log4j est une liste blanche de désérialisation basée sur resolveClass. Sa liste blanche inclut java.rmi.MarshalledObject. Un MarshalledObject stocke sa charge utile sous forme de byte[] opaque, et MarshalledObject.get() désérialise cette charge utile sur un ObjectInputStream frais et non filtré — la liste blanche n'inspecte donc jamais le graphe interne.

Log4j déclenche cela lui-même : Log4jLogEvent$LogEventProxy (la forme filaire sérialisée d'un LogEvent, depuis 2.8) transporte le Message de l'événement dans un MarshalledObject et appelle .get() automatiquement pendant la désérialisation (readResolve() → message()). Toute application qui lit un LogEvent sérialisé via FOIS effectue donc une désérialisation non filtrée d'octets attaquants — et comme message() avale l'exception résultante et retombe sur SimpleMessage, le récepteur journalise un événement bénin et continue de fonctionner. L'exploit est silencieux.

Cause racine (vérifiée contre rel/2.26.1)

Ce que le laboratoire exécute

Un substitut fidèle du ObjectInputStreamLogEventBridge déprécié de log4j-samples : un récepteur TCP non authentifié qui lit un LogEvent sérialisé par connexion via FOIS. L'attaquant envoie un seul objet sérialisé ; l'oracle est un fichier de preuve écrit dans un répertoire monté en bind uniquement dans le conteneur du récepteur, de sorte que son apparition prouve que du code s'est exécuté dans le récepteur via la désérialisation.

rce = code exécuté. reject = FOIS a levé une exception sur le flux externe. silent = objet externe traité, aucun code exécuté (bloqué plus profondément, ou version du gadget sûre).

Exécution

Prérequis : Docker uniquement (un JDK est tiré comme eclipse-temurin:17-jdk). Le script télécharge les jars officiels et les vérifie contre les SHA-1 de Maven Central avant utilisation. Épinglez une version Log4j différente dans la plage vulnérable avec LOG4J_VERSION=2.20.0 ./run.sh.

Impact et méthode d'attaque

• Livraison : une seule écriture TCP non authentifiée d'environ 2,8 Ko d'un LogEvent sérialisé vers un récepteur basé sur FOIS. Ce n'est pas déclenchable en faisant journaliser une chaîne (contrairement à Log4Shell) — il faut des octets sérialisés bruts atteignant le pont socket.
• Résultat : exécution arbitraire de commandes dans le processus du récepteur, silencieusement.
• Chemin d'attaque : construire un LogEvent → writeReplace()/writeObject() de Log4j enveloppe le Message dans un MarshalledObject → le gadget se cache dans son byte[] opaque → sur le récepteur, readResolve() → message() → MarshalledObject.get() ouvre un flux non filtré frais → gadget → Runtime.exec. src/attacker/Attacker.java (poc2) insère un graphe pure-CommonsCollections6 dans objBytes du MarshalledObject, donc aucune classe attaquante n'est nécessaire sur la victime.

Atténuation

• Fiable : -Djdk.serialFilter='!java.rmi.MarshalledObject' sur la JVM du récepteur (S5). Mise en garde : cela bloque aussi les objets LogEventProxy sérialisés légitimes (ils utilisent MarshalledObject également) — c'est efficace mais pas transparent pour le transport de journaux sérialisés.
• Non fiable : filtres génériques maxdepth/maxbytes. Le filtre à l'échelle du processus se propage dans le flux MarshalledObject interne et la profondeur y redémarre, donc maxdepth=5 bloque CC6 (S6) mais un gadget peu profond passerait. Dépendant de la profondeur de chaîne, pas une frontière.
• Structurel : éliminer le transport de journaux sérialisés Java (utiliser JSON / RFC 5424 sur TLS authentifié) ; supprimer les dépendances de gadgets connues ; ne pas exposer les récepteurs sérialisés hérités à des réseaux non fiables. Correctif en amont (selon le problème) : retirer MarshalledObject de la liste blanche et déplacer le message marshallé vers writeWrappedObject/readWrappedObject filtrés de Log4j.

Portée et limites honnêtes

• Conditionnel à l'application, pas une RCE Log4j générale. Cela nécessite une application qui expose un récepteur de LogEvent sérialisé non authentifié basé sur FOIS et qui a une version de gadget utilisable sur son classpath. Les déploiements Log4j ordinaires n'exécutent aucun récepteur de ce type.
• Le serveur socket sérialisé dans le noyau n'a existé que jusqu'à 2.8.2 (net.server.TcpSocketServer a été déplacé hors de log4j-core en 2017 ; absent à partir de 2.9.0). Les récepteurs modernes sont du code d'application/échantillon, ce que ce laboratoire modélise.
• Dépendant de la version du gadget. commons-collections 3.2.1 → RCE ; 3.2.2 le bloque (S7). Tout gadget utilisable suffit, mais « avoir commons-collections » n'est pas en soi suffisant.
• uid=0 dans le laboratoire est root de conteneur — il n'y a pas d'évasion Docker ; la RCE s'exécute comme le processus du récepteur.
• La primitive (MarshalledObject contournant un filtre resolveClass) est un art antérieur connu ; voir la discussion Apache #4168 (« Log4j 2.x deserialization hardening »). Le déclenchement automatique spécifique à Log4j est la contribution de #4255.

Structure

Références

• Problème #4255 — https://github.com/apache/logging-log4j2/issues/4255
• Discussion #4168 (durcissement de la désérialisation) — https://github.com/apache/logging-log4j2/discussions/4168
• FAQ Log4j CWE-502 — https://logging.apache.org/security/faq.html
• Avis de sécurité Apache Commons Collections — https://commons.apache.org/proper/commons-collections/security.html

Crédits

Vulnérabilité signalée par U-Sec (Wujie Security) dans Apache log4j2 #4255. Ce dépôt est un laboratoire indépendant de reproduction/validation pour la recherche défensive et l'ingénierie de détection.