Without alpine image, Log4j don't follow Exploit*.class
mhagnumdw opened this issue · comments
If I change container image from openjdk:8u181-jdk-alpine to openjdk:8u181-jdk, the vulnerability does not occur.
Log4j don't follow http://my-ip:8888/Exploit*.class.
I confirm I'm able to reproduce the behavior. Would you have any guess as to why the exploit is not working on the non-Alpine version? It's using the same JDK version (1.8.0_181), and I don't know of reason why it wouldn't be working
I still don't know and I haven't been able to investigate much. But I imagine that log4j changes flow due to some environment difference: environment variable, OS configuration etc.
That's useful info. Given that the goal of this repo is to provide a purposely vulnerable application, I suggest we close the issue.
You need to set com.sun.jndi.ldap.object.trustURLCodebase=true for the JVM via JAVA_TOOL_OPTIONS or any other means to make the app vulnerable. It should then work with any Linux image. I'm using this in a VM directly, and not docker.
Thanks so much for this @christophetd
Do you think that the JDK's are being patched to disable this class loading behaviour via JNDI?
I could reproduce the attack today in an Ubuntu VM with the JDK 1.8 u181.
To summarize, there seems to be no issue with the current repository, so I'll go ahead and close the issue. Thanks