I'm not sure why some people have zero-byte jar files (download failure?) but the program crashes in that circumstance.

While scanning nested .jar files, the scanner exiting with an error:

./local-log4j-vuln-scanner  --exclude /proc  /
local-log4j-vuln-scanner - a simple local log4j vulnerability scanner

OUTPUT
cant't open JAR file: /../../../FOO-1.0.0-BAR.jar (size 19165951): zip: not a valid zip file
….

manual unzipping the file work's fine

unzip -l /../../../FOO-1.0.0-BAR.jar
Archive:  /../../../FOO-1.0.0-BAR.jar
warning [ /../../../FOO-1.0.0-BAR.jar ]:  8500 extra bytes at beginning or within zipfile
  (attempting to process anyway)

As this is not that critical it's nice to add. https://thehackernews.com/2021/12/apache-issues-3rd-patch-to-fix-new-high.html?m=1

Since CVE-2021-44228 is fixed in 2.15.0, this scanner should not report log4j-core-2.15.0.jar

> curl -LO https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/log4j-core-2.15.0.jar

> sha256sum log4j-core-2.15.0.jar 
419a8512895971b7b4f4f33e620d361254e5c9552b904b0474b09ddd4a6a220b  log4j-core-2.15.0.jar

> ./local-log4j-vuln-scanner - a simple local log4j vulnerability scanner
indicator for vulnerable component found in log4j-core-2.15.0.jar (org/apache/logging/log4j/core/net/JndiManager$1.class): log4j 2.13.0-2.15.0
Scan finished

To address this, the scanner could cross-check the hash of MessagePatternConverter from apache/logging-log4j2#608.

I am new in GoLang but anyway not sure if it is done by intention :)

If the tool scan a directory which ends with ".war" it seems that the program handle the directory as zipped file (and tries to extract the file).
The result is an error output like "the handle is invalid"

I need to exclude huge amounts of similar folders.
Is it possible to add wildcard support for the exclude parameter?

Hi

I have noticed that upon rerunning the scanner against WAR files that have had the patcher run against them, the same vulnerability is showing up. For example, where ws.war.original.war is the original (unpatched) copy of a WAR file and ws.war is the patched copy:

# ./local-log4j-vuln-scanner-0.8.1 --ignore-v1 --exclude /proc --exclude /run/user /var/lib/docker/overlay2/02ac4e5dc4f93ebd2d37f5df4d517473cbe2384d908fa0c016a5499c51684828/diff/usr/local/tomcat/webapps
local-log4j-vuln-scanner-0.8.1 - a simple local log4j vulnerability scanner

indicator for vulnerable component found in /var/lib/docker/overlay2/02ac4e5dc4f93ebd2d37f5df4d517473cbe2384d908fa0c016a5499c51684828/diff/usr/local/tomcat/webapps/ws.war::WEB-INF/lib/log4j-core-2.3.jar (org/apache/logging/log4j/core/net/JndiManager.class): log4j 2.1-2.3
indicator for vulnerable component found in /var/lib/docker/overlay2/02ac4e5dc4f93ebd2d37f5df4d517473cbe2384d908fa0c016a5499c51684828/diff/usr/local/tomcat/webapps/ws.war.original.war::WEB-INF/lib/log4j-core-2.3.jar (org/apache/logging/log4j/core/net/JndiManager.class): log4j 2.1-2.3

Scan finished

I should expect the vulnerability not to be flagged in the patched version.

Kind regards.

Virustotal indicated the .exe file 17 security vendors and 1 sandbox flagged this file as malicious. Is this false positive?
https://www.virustotal.com/gui/file/9475f529d96d306d52d050cf816712894fc082da863b733cae22f9dbd3b433bd

There is at least one library which shades log4j, packaging the class as .esclazz. I have no idea why.

https://github.com/elastic/apm-agent-java

Can we add scanning support for these files?

Thanks for the great tool!
I understand that the detection is done by checking for presence of the JndiManager.class in versions 2.1 and up.

However my understanding is that removing JndiLookup.class should be sufficient to mitigate the issue. I know that there is some conflicting information regarding this out there (whether to remove both the lookup and the manager class or only the lookup), but based on the official communication by apache removing the JndiLookup.class should be sufficient:

Otherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046

Is there any concrete information out there that JndiManager.class really needs to be removed too? If not it could make sense to change the detection to be based on the Lookup's class presence for accurate results

Hi,

the switch seems not to be active in 0.6

flag provided but not defined: -ignore-v1
Usage of ./files/local-log4j-vuln-scanner:
  -exclude value
        paths to exclude
  -log string
        log file to write output to
  -verbose
        log every archive file considered

Thanks in advance.

With the latest version of the tool I am getting lots of warning messages to STDOUT (not STDERR) like these. Does the tool need to warn about not being able to read magic?

can't read magic from JAR file member: /opt/android-studio/lib/batik-codec-1.12.0-8.jar (org/apache/batik/ext/awt/image/codec/properties): EOF
can't read magic from JAR file member: /opt/android-studio/lib/istack-commons-runtime-3.0.7.jar (.gitkeep): EOF
can't read magic from JAR file member: /opt/android-studio/lib/resources_en.jar (fileTemplates/internal/CMakeLists.txt.cmake.ft): EOF
can't read magic from JAR file member: /opt/android-studio/lib/spellchecker.jar (com/intellij/spellchecker/excluded.dic): EOF
can't read magic from JAR file member: /opt/android-studio/lib/tips-intellij-idea-community-193.4.jar (tips/bundle.version): EOF
can't read magic from JAR file member: /opt/android-studio/lib/xmlpull-1.1.3.1.jar (XMLPULL_1_1_3_1_VERSION): EOF
can't read magic from JAR file member: /opt/android-studio/lib/xpp3_min-1.1.4c.jar (XPP3_1.1.4c_MIN_VERSION): EOF

In the scanner, the file name extensions are hard-coded to jar/war/ear; at least rar (resource adapter archive) is missing.
It would be a great improvement to configure the file names to match on the command line, e.g., log4j-vuln-scanner --jarfiles jar,war,ear,rar

Hi

The scanner (both versions 0.8.1 and 0.9) gives a strange "indicator" message for one of our JARs:

indicator for vulnerable component found in _<path>_/neo4j-logging-4.3.2.jar (org/neo4j/logging/shaded/log4j/core/net/JndiManager.class): JndiManager class missing new error message string literal

Is this working as intended?

This is probably strongly related to issue #34 .

Kind regards.

Hi

Using release 0.9, the scanner is now giving very many "can't read magic from JAR file member" messages. This did not happen in release 0.8.1. I'm not sure that the fix that went into 0.9 is working as you intended.

Kind regards.

Possibly due to my own lack of experience with go, but the Readme instructs using ./log4j-vuln-scanner but there is no executable by that name in this repo. Is this something that would be created in a previous step?

In the 0.4 release there is a ".macos" file. However, this is not a standard extension for macos executables. Should this be run without that extension?

Are they false positives?
https://www.virustotal.com/gui/file/6e472463ae43279ea09bfa4aac8d6d2a544104fde83e2e4bb52808f6aae761a2?nocache=1
Got the file from oldgamesdownload.com

With Windows 10, running "go run main.go <filepath>" (within scanner) does well.
With Windows 10, running "go run main.go -help" (within scanner) does well.
With Windows 10, running "go run filter.go" fails with "package command-line-arguments is not a main package".
With Windows 10, running "go run filter.go -help" fails with "package command-line-arguments is not a main package".
Pardon I'm a newbie. Any hints?

Because Apple is dumb, they've placed both the Data partition and network shares in /System/Volumes

Can we add a flag to have it not scan network shares?

see https://logging.apache.org/log4j/2.x/security.html#Fixed_in_Log4j_2.17.0_.28Java_8.29
and https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105

We are using your scanner tool to scan user home directories which are hosted on AFS, this used to work perfectly but the latest version now seems to ignore them. For example:

"""
./local-log4j-vuln-scanner /afs/example.org/user/bob
local-log4j-vuln-scanner - a simple local log4j vulnerability scanner

Checking for vulnerabilities: CVE-2019-17571, CVE-2021-44228, CVE-2021-45105
Skipping /afs/example.org/user/bob: pseudo or network filesystem

Scan finished
"""

I can see this affecting other sites which similarly use NFS or samba for user home directories. Could the skipping of network file please be made optional.

Thanks,

Stephen Quinney

Is it intended that this utility will flag 1.X versions? It has been stated that "As log4j 1.x does NOT offer a look-up mechanism, it does NOT suffer from CVE-2021-44228". Does this mean that 1.X versions can and should be disregarded?

Thx

Issue is that the walking of the root includes mounted drives, which causes it to walk very large filesystems, and this caused OOM on our servers.

Hi, just a minor documentation issue: in https://github.com/hillu/local-log4j-vuln-scanner#using-the-patch-tool the executable name is given as "log4j-vuln-patcher". The downloaded executable is actually "local-log4j-vuln-patcher".

Hey there,
i just wanted to ask if the scanner is updated and detects the CVE-2021-45046 too.

In short: log4j 2.15.0 is vulnerable too and needs to be updated to version 2.16.0

Source:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

Thanks in advance.

Adding a workflow for arm64 build for m1 macs and other arm64 devices

Could you please add a feature to install the scanner using "go install" ?

eg:
go install github.com/hillu/local-log4j-vuln-scanner@latest

According to https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046 version 2.12.2 was released with a fix and does not contain the vulnerability:

All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2

So it would be great if this can be excluded from being flagged as vulnerable. It seems that the JndiManager.class has its hash unchanged in 2.12.2 becasue it is still detected as log4j 2.12.0-2.12.1

Sorry, really new to Go. I can't seem to get this to work on windows x86 machines. I repeatedly get a message, This executable is not compatible with the version of windows you are running. It is only happening on win7 x86 intel machines. Am I just missing something obvious?

There is a "problem" with excluding paths in Linux (maybe intended, but then needs to be added to help):

Usage can be:
[-]-exclude[=]/path/to/exclude
[-]-exclude[=]/path/to/exclude/*
What does not work is:
[-]-exclude[=]/path/to/exclude/ # when path ends with "/" is not excluded (often when auto-completion is used)

Help is not clear as well:

-exclude value
paths to exclude

Actually it is only one path_ but you can specify exclude multiple times.

BTW: Thanks for the scanner!