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

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)

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?

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

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.

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

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?

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

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?

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

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

This adds the CVE-2021-45105 vulnerability (log4j-core-2.16.0) and the CVE-2021-44832 vulnerability (log4j-core-2.17.0) to the scanner.

The changes from @L0u15 out of #43 are already part of this PR. README was also updated.

I tested this on my local Win10 machine as well as on a WinServer 2016 and it worked there.

We have been using this code to check for log shell CVE and wanted to also have it find the new chainsaw cve, so a small update to the config in Filter.

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?

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

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