This is starting to look like a gong show. log4j 2.15 has been replaced by an updated fix (2.16) today as they already found a bypass to the fix on Friday.
Worse ... lunasec just released a tool and mitigation guide at:
https://www.lunasec.io/docs/blog/log4j- ... ion-guide/
Code: Select all
mkdir log4shell
cd log4shell
wget https://github.com/lunasec-io/lunasec/releases/download/v1.0.0-log4shell/lunasec_1.0.0-log4shell_Linux_x86_64.tar.gz
tar xvf lunasec_1.0.0-log4shell_Linux_x86_64.tar.gz
# as root
# ./log4shell scan /opt/zimbra
12:41AM INF identified vulnerable path fileName=org/apache/log4j/net/SocketNode.class path=/opt/zimbra/jetty_base/common/lib/log4j-1.2.16.jar versionInfo="log4j 1.2.16"
12:41AM INF identified vulnerable path fileName=org/apache/log4j/net/SocketNode.class path=/opt/zimbra/lib/jars/log4j-1.2.16.jar versionInfo="log4j 1.2.16"
This is because of CVE-2019-17571 which has recently been revised. see:
https://nvd.nist.gov/vuln/detail/CVE-2019-17571
The exact problem is: "For Apache log4j versions from 1.2 (up to 1.2.17), the SocketServer class is vulnerable to deserialization of untrusted data, which leads to remote code execution if combined with a deserialization gadget.".
Ref:
https://unit42.paloaltonetworks.com/apa ... 021-44228/
I guess we are too take them at their word that they looked into their code because it kind of looks like CVE-2019-17571 is a problem. It could also be that lunasec has included this hash when it should not have been but more than likely they feel that CVE-2019-17571 is a concern with so many eyes on CVE-2021-44228.
Note: in this thread khawkins and michnovka have already mentioned CVE-2019-17571 but something feels off that I can't rationalize myself. Maybe its the trusting of a software module that would execute any binary sent by an untrusted client is the cause.

I opened a ticket because if anything detailing pathways for a RCE only leads to more problems so I'll end it here.
Jim