Without alpine image, Log4j don't follow Exploit*.class

[mhagnumdw]

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.

[christophetd]

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

[mhagnumdw]

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.

[christophetd]

That's useful info. Given that the goal of this repo is to provide a purposely vulnerable application, I suggest we close the issue.

[venkyr]

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

[ranavikrant3]

Do you think that the JDK's are being patched to disable this class loading behaviour via JNDI?

[montao]

I could reproduce the attack today in an Ubuntu VM with the JDK 1.8 u181.

[christophetd]

To summarize, there seems to be no issue with the current repository, so I'll go ahead and close the issue. Thanks