Closed vosskaem closed 2 years ago
Thanks !!!! Guess the symlink cycle detection is not quite right - ugh...
Try now ?
I've pushed back the previous log4j-detector-2021.12.14.jar pre-compiled binary in case this infinite loop is still a problem.
Would love a test case if you have one. Haven't been able to reproduce this over here yet.
Unfortunately I have to go to sleep now, but I really appreciate this bug report - thank you !!!!!
I worked on a rewrite that will not try to load files in memory anymore and scan them streamlined. Maybe we can try to merge the versions. I am not sure, why you took the approach of a "getFreshZipStream" and all that trying to find the beginning of the zip stream in the file but it seems we should not copy stuff in memory. If you want we can discuss. See this version: https://github.com/domoran/log4j-detector/blob/master/src/main/java/com/continental/swx/log4jscan/Log4JScan.java
Using 8fa4c766f0b22f9cf5d46d15c49924417c92034f it woks:
java -jar log4j-detector-2021.12.15.jar /opt/
-- github.com/mergebase/log4j-detector v2021.12.15 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
-- Problem /opt/omni/AppServer/modules/system/layers/base/com/h2database/h2/main/h2-1.4.193.jar!/org/h2/util/data.zip - java.util.zip.ZipException: unexpected EOF
/opt/omni/AppServer/modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.2.0.Final.jar contains Log4J-1.x <= 1.2.17 _OLD_ :-|
/opt/omni/bin/telemetry/log4j-core-2.11.2.jar contains Log4J-2.x >= 2.10.0 _VULNERABLE_ :-(
Closing this as fixed!
@domoran - can you create a ticket so i don't forget your idea to improve the memory overhead?
Using log4j-detector-2021.12.15.jar on Red Hat Enterprise Linux release 8.5 (Ootpa) with openjdk version "1.8.0_312" The following output is from infinite loop: