search

mergebase / log4j-detector

A public open sourced tool. Log4J scanner that detects vulnerable Log4J versions (CVE-2021-44228, CVE-2021-45046, etc) on your file-system within any application. It is able to even find Log4J instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and everywhere else Java runs, too! TAG_OS_TOOL, OWNER_KELLY, DC_PUBLIC
Other
638 stars 98 forks source link

Hard to tell if program works as expected: Simple test case fails #12

Closed yspreen closed 2 years ago

yspreen commented 2 years ago 
mkdir tmp; cd tmp
mkdir -p appender/nosql core
touch "core/LogEvent.class"
touch "core/Appender.class"
touch "core/Filter.class"
touch "core/Layout.class"
touch "core/LoggerContext.class"
touch "appender/nosql/NoSqlAppender.class"
touch "JndiLookup.class"
java -jar ~/Downloads/log4j-detector-2021.12.13.jar . --verbose

results in

-- Analyzing paths (could take a long time).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
-- Examining ./appender/nosql/NoSqlAppender.class... 
-- Examining ./core/Appender.class... 
-- Examining ./core/Filter.class... 
-- Examining ./core/Layout.class... 
-- Examining ./core/LogEvent.class... 
-- Examining ./core/LoggerContext.class... 
-- Examining ./JndiLookup.class... 
-- No vulnerable Log4J 2.x samples found in supplied paths: [.]
-- Congratulations, the supplied paths are not vulnerable to CVE-2021-44228 !  :-)

from what I can tell, this should report the vuln

juliusmusseau commented 2 years ago

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.

yspreen commented 2 years ago

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

yspreen commented 2 years ago

@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

juliusmusseau commented 2 years ago

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.

yspreen commented 2 years ago

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
juliusmusseau commented 2 years ago

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 !

datacamp461 commented 2 years ago

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 "

juliusmusseau commented 2 years ago

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

yspreen commented 2 years ago

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

juliusmusseau commented 2 years ago

@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
yspreen commented 2 years ago

maybe try a project built with jdk 8

On Tue, Dec 14, 2021 at 2:04 AM mergebase.com @.***> wrote:

@yspreen https://github.com/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

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/mergebase/log4j-detector/issues/12#issuecomment-993058359, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAL3ZZUJQHMD23QZEZB6RLUQ2JZDANCNFSM5J6HC7UA .

-- Yannick Spreen

juliusmusseau commented 2 years ago

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

Lurkars commented 2 years ago

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!

yspreen commented 2 years ago

yea it’s spring boot

On Tue, Dec 14, 2021 at 9:31 AM Lurkars @.***> wrote:

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!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mergebase/log4j-detector/issues/12#issuecomment-993292986, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAL3Z74QUMFN2XKOHLBI4TUQ36FTANCNFSM5J6HC7UA .

-- Yannick Spreen

juliusmusseau commented 2 years ago

I think this is fixed now !