How to mitigate Apache Log4j Deserialization RCE (CVE-2019-17571)

user_13919748 0
Viewed 6038

I have upgraded my log4j-core dependency to 2.15.0 in order to prevent any potential Log4Shell attack. That being said I could not upgrade slf4j-log4j12's indirect log4j dependency from 1.2.17 since the latest stable version of slf4j-log4j12 is still dependent on log4j 1.2.17. This still leaves my webapp vulnerable to CVE-2019-17571 if I am not mistaken. So reading about possible mitigation strategies I came across this article which recommends to :

prevent the socket port enabled by the SocketServer class in Log4j from being opened to the public network

Could anyone please explain to me how can this be achieved and whether would this workaround be sufficient?

log4j java
1 Answers

Only servers that receive messages from other servers are vulnerable to CVE-2019-17571. Basically the only way to trigger the vulnerability is to run:

java -jar log4j.jar org.apache.log4j.net.SocketServer <port> <config.properties> <log/directory>

or doing the equivalent in code. Therefore most Log4j 1.2 users are not vulnerable.

In your case, however, you just need to replace the slf4j-log4j12 binding with its Log4j 2.x equivalent (log4j-slf4j-impl) and you can remove Log4j 1.2 altogether.

Edit: Nevertheless, if you want to be certain no one will use the library as above, you can remove the class. Considering also CVE-2021-4104 this amount to:

zip -d log4j.jar org/apache/log4j/net/SocketServer.class
zip -d log4j.jar org/apache/log4j/net/JMSAppender.class
user_117484540
Related