
An agent to hotpatch the log4j RCE from CVE-2021-44228.
Cet outil injecte un agent Java dans un processus JVM en cours d'exécution. L'agent tente de corriger la méthode lookup() de toutes les instances chargées de org.apache.logging.log4j.core.lookup.JndiLookup afin de retourner inconditionnellement la chaîne "Patched JndiLookup::lookup()". Il est conçu pour répondre à la vulnérabilité d'exécution de code à distance CVE-2021-44228 dans Log4j sans redémarrer le processus Java. Cet outil répond également à la CVE-2021-45046.
Il a été testé uniquement avec JDK 8, 11, 15 et 17 sur Linux !
Pour construire sur Linux, Mac et le sous-système Windows pour Linux
./gradlew build
Pour construire sur Windows
.\gradlew.bat build
Selon la plateforme sur laquelle vous construisez. Cela générera build/libs/Log4jHotPatch.jar
Pour construire avec Maven, utilisez
mvn clean package
Cela générera un target/Log4jHotPatch.jar.
JDK 8
java -cp <java-home>/lib/tools.jar:Log4jHotPatch.jar Log4jHotPatch <java-pid>
JDK 11 et plus récent
java -jar Log4jHotPatch.jar <java-pid>
Ajoutez simplement l'agent à votre ligne de commande Java comme suit :
java -classpath <class-path> -javaagent:Log4jHotPatch.jar <main-class> <arguments>
Il existe un ensemble de tests qui peuvent être exécutés en dehors de Gradle ou Maven.
build-tools/bin/run_tests.sh Log4jHotPatch.jar <JDK_ROOT>
Si vous obtenez une erreur comme :
Exception in thread "main" com.sun.tools.attach.AttachNotSupportedException: The VM does not support the attach mechanism
at jdk.attach/sun.tools.attach.HotSpotAttachProvider.testAttachable(HotSpotAttachProvider.java:153)
at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56)
at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
at Log4jHotPatch.loadInstrumentationAgent(Log4jHotPatch.java:115)
at Log4jHotPatch.main(Log4jHotPatch.java:139)
cela signifie que votre JVM refuse toute aide car elle est exécutée avec -XX:+DisableAttachMechanism.
Si vous obtenez une erreur comme :
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not responding or HotSpot VM not loaded
at sun.tools.attach.LinuxVirtualMachine.<init>(LinuxVirtualMachine.java:106)
at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:63)
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
at Log4jHotPatch.loadInstrumentationAgent(Log4jHotPatch.java:182)
at Log4jHotPatch.main(Log4jHotPatch.java:259)
cela signifie que vous exécutez en tant qu'utilisateur différent (y compris root) de la JVM cible. JDK 8 ne peut pas gérer le patch en tant qu'utilisateur root (et déclenche un vidage de threads dans la JVM cible, ce qui est inoffensif). Sous JDK 11, patcher un processus non-root depuis un processus root fonctionne sans problème.
Si vous obtenez une erreur comme celle-ci dans le processus cible :
Exception in thread "Attach Listener" java.lang.ExceptionInInitializerError
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:386)
at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)
Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "log4jFixerAgentVersion" "write")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:886)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.System.setProperty(System.java:794)
at Log4jHotPatch.<clinit>(Log4jHotPatch.java:66)
cela signifie que le processus cible a un gestionnaire de sécurité installé. Cherchez cette option de ligne de commande dans le processus cible :
-Djava.security.policy=/local/apollo/.../apollo-security.policy
Si vous rencontrez cette erreur, assurez-vous d'utiliser la dernière version de l'outil
Important : Si vous avez tenté de patcher en tant que mauvais utilisateur, vous devrez peut-être supprimer les fichiers .attach_pid<pid> (situés dans /tmp et/ou le répertoire de travail courant du processus VM) avant de réessayer. Ces fichiers doivent avoir le bon propriétaire pour que l'attachement réussisse.