Hard to tell if program works as expected: Simple test case fails about log4j-detector HOT 15 CLOSED

Throw those files into a zip file. :-)

But I plan to fix the tool to detect unzipped Log4J, too (a rare but not impossible scenario). Stay tuned.

from log4j-detector.

we had the problem that about half of our jar files silently failed. the jar's within were never scanned, and the verbose flag confirmed that they weren't found by the tool. hence the attempt to unzip first

from log4j-detector.

@juliusmusseau this is what happens with the project in question. freshly built jar from jdk 8. sadly cannot share because it's closed source:

(.pyenv) ➜  docker git:(master) ✗ ls -lA
total 145056
-rwxr--r--  1 user  staff  74268625 Dec 13 17:45 application.jar
(.pyenv) ➜  docker git:(master) ✗ java -jar ~/Downloads/log4j-detector-2021.12.13.jar . --verbose
-- Analyzing paths (could take a long time).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
-- Examining ./application.jar... 
-- No vulnerable Log4J 2.x samples found in supplied paths: [.]
-- Congratulations, the supplied paths are not vulnerable to CVE-2021-44228 !  :-) 
(.pyenv) ➜  docker git:(master) ✗ unzip application.jar >/dev/null 2>/dev/null
(.pyenv) ➜  docker git:(master) ✗ find . -iname '*.jar' | wc -l
     202
(.pyenv) ➜  docker git:(master) ✗ 

subsequently calling the script with --verbose does scan all the 202 jar files. but recursion is definitely not working here

from log4j-detector.

Can you try now? (Do a "git pull --rebase" first, or re-download the log4j-detector-2021.12.13.jar). I added some additional logging messages to get a better sense of what is going on.

from log4j-detector.

same result

(.pyenv) ➜  docker git:(master) ✗ rm -rf BOOT-INF META-INF org                                   
(.pyenv) ➜  docker git:(master) ✗ java -jar ~/Downloads/log4j-detector-2021.12.13.jar . --verbose
-- Analyzing paths (could take a long time).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
-- Examining ./application.jar... 
-- No vulnerable Log4J 2.x samples found in supplied paths: [.]
-- Congratulations, the supplied paths are not vulnerable to CVE-2021-44228 !  :-) 
(.pyenv) ➜  docker git:(master) ✗ md5 ~/Downloads/log4j-detector-2021.12.13.jar        
MD5 (/Users/user/Downloads/log4j-detector-2021.12.13.jar) = 26ddfb12004b3ba7a6261e33a9d49efb

from log4j-detector.

This one is real Java koan ! I've been meditating on it all morning.

Can you try with latest version and add the new "--debug" flag I've added, and see if that gives you any ideas for what might be going wrong?

(I also rejigged the way inner zip files are detected, but I think there's only a small 10% chance that actually fixes things here.)

Note: --debug really causes a lot of noise on STDERR. Sorry !

from log4j-detector.

in my case it dont recognize jar files with the affected log4j versions, for example 2.14.1?

I tested with several examples and everytime says " No vulnerable Log4J 2.x samples found "

from log4j-detector.

@datacamp461 - are you able to share a sample with me that I can test in my lab?

from log4j-detector.

in my case the debug flag doesn't print anything at all. a previous version didn't recognize the flag and threw an error but now the output is exactly the same with or without

from log4j-detector.

@yspreen - that's actually helpful!

It's supposed to print things like this (for every entry inside the zip):

-- DEBUG - /var/tmp/l/l.zip!/l/2.0-alpha1/org/apache/logging/log4j/core/config/NullConfiguration.class size=895 isZip=false isClass=true
-- DEBUG - /var/tmp/l/l.zip!/l/2.0-alpha1/META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties size=124 isZip=false isClass=false
-- DEBUG - /var/tmp/l/l.zip!/l/2.0-alpha1/log4j-core-2.0-alpha1.jar size=375010 isZip=true isClass=false

from log4j-detector.

from log4j-detector.

Any chance your jar file is a spring-boot executable jar ?

from log4j-detector.

Any chance your jar file is a spring-boot executable jar ?

I can confirm on this: a spring-boot executable jar file does NOT get recognized by this tool!

from log4j-detector.

from log4j-detector.

I think this is fixed now !

from log4j-detector.