search

google / log4jscanner

A log4j vulnerability filesystem scanner and Go package for analyzing JAR files.
Apache License 2.0
1.56k stars 121 forks source link

False positive with current detection method #43

Closed nikaiw closed 2 years ago

nikaiw commented 2 years ago

The apache foundation continue to maintains log4j version specifically compatible with JVM7 and JVM6.

Thus: - version 2.12.2 (Java7) and version 2.3.1 (Java6) came out with patch like 2.16.0.

Unfortunately current detection stategy detect those version as vulnerable.

It is all the more unfortunate since the little brittle of checking the presence of "isJndiEnabled" seems a sufficient method for the moment.

As an example running the following command on a directory with all the existing log4j 2 branche will show all the patched version :

for i in $(ls -1 *.jar);do;if unzip -p $i org/apache/logging/log4j/core/net/JndiManager.class|grep -q isJndiEnabled;then echo $i;fi;done 2>/dev/null
log4j-core-2.12.2.jar
log4j-core-2.12.3.jar
log4j-core-2.12.4.jar
log4j-core-2.16.0.jar
log4j-core-2.17.0.jar
log4j-core-2.17.1.jar
log4j-core-2.3.1.jar
log4j-core-2.3.2.jar

Running the log4scanner on the same directory with debug print()

[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.1.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.10.0.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.11.0.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.11.1.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.11.2.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.12.0.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.12.1.jar
[216Pattern] [216Pattern.*YARARulePattern] [YARARulePattern.*216Pattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.12.2.jar
[216Pattern] [216Pattern.*YARARulePattern] [YARARulePattern.*216Pattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.12.3.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.13.0.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.13.1.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.13.2.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.13.3.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.14.0.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.14.1.jar
[Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.15.0.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.2.jar
[216Pattern.*YARARulePattern] [YARARulePattern.*216Pattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.3.1.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.3.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.4.1.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.4.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.5.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.6.1.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.6.2.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.6.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.7.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.8.1.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.8.2.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.8.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.9.0.jar
[YARARulePattern] [Vulnerable]: /home/user/lab/log4j-all/log4j-core-2.9.1.jar

We can see that 2.12.2, 2.12.3, 2.3.1 are matching the 216Pattern + Yara rule pattern and are wrongly detected as vulnerable

ericchiang commented 2 years ago

cc @ddworken

ericchiang commented 2 years ago

This reflects some of our internal expectations that users must upgrade to +2.16.x.

I don't really have a good answer for this request. The heuristics are brittle because JARs don't provide dependency version information in the archive. Also, supporting versions of Java that are end-of-lifed (Java 6) or end-of-lifed without a support contract (Java 7) isn't a high priority for us.

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

We can definitely document this. I don't think we'd want to take code changes though (maybe an external hook?).

nikaiw commented 2 years ago

I understand the point of view, althought in my opinion this might give a false feeling of insecurity to application owners who would have a jvm7/jvm 6 application which was already updated to latest available log4j libraries.

Moreover, solving the problem looks (at first glance) easy and would simplify the detection method. ( I think it should at least be documented as the purpose of the scanner is to find vulnerable libraries and it is currently reporting non-vulnerable one).