Log4jscanner(github.com)
github.com
Log4jscanner
https://github.com/google/log4jscanner
41 comments
For Java projects, we use OWASP dependency check as a Maven plugin, which fails the build if compromised log4j2 deps exist: https://owasp.org/www-project-dependency-check/
this is much better tool from Java developer's perspective.
The essence is: https://github.com/google/log4jscanner/blob/main/jar/jar.go
this is the decision logic:
func (c *checker) bad() bool {
return (c.hasLookupClass && c.hasOldJndiManagerConstructor) || (c.hasLookupClass && c.seenJndiManagerClass && !c.isAtLeastTwoDotSixteen)
}
this is the decision logic:
func (c *checker) bad() bool {
return (c.hasLookupClass && c.hasOldJndiManagerConstructor) || (c.hasLookupClass && c.seenJndiManagerClass && !c.isAtLeastTwoDotSixteen)
}
It is a lot of code for just that.
I’d argue that the convenience of this tool isn’t just the fact that it can tell a class/jar is “bad”, but the convenience of being able to automatically scan the filesystem to do that.
And most of the code I see is about walking the filesystem, unzipping jars, walking the files inside the jars.
Most codebases have this kind of plumbing all the time.
And most of the code I see is about walking the filesystem, unzipping jars, walking the files inside the jars.
Most codebases have this kind of plumbing all the time.
the story of browsing through code: "I'm wasting my time reading this", until you read the 3 lines that actually matter.
I feel like this is a missed opportunity to use a name like scan4log4j
logsk&
Loggy McLogface
Like the other Google project, Bloaty McBloatface.
https://github.com/google/bloaty
Like the other Google project, Bloaty McBloatface.
https://github.com/google/bloaty
As someone who hasn't touched Java since a programming class 20 years ago, and mostly lives in the Node world now, with sprinkles of Python, is it enough to simply scan jar files? Do I need to worry about a Linux VPS running a Node app that might install some kind of Java dependency somewhere?
One of the benefits of this tool is that you can run it across a folder or even an entire disk to check all jars on the disk. So if a Node app does somehow pull in java, by scanning the entire disk this tool should be able to detect if the pulled in java code contains log4j.
A Node or Python program could indirectly use a java library but it would be very unusual, and this library should catch it assuming any amount of sanity in how the dependency is installed.
Theoretically, some particularly insane application could download and run a jar purely in memory without it ever touching the disk. That's so close to malware-like behavior that only the most insane legit programs would ever do that.
Theoretically, some particularly insane application could download and run a jar purely in memory without it ever touching the disk. That's so close to malware-like behavior that only the most insane legit programs would ever do that.
It wouldn't be safe against an someone who actively tries to hide code, but the classloader requires the class files to be appropriately named, so if unzip -l doesn't show any suspect class names that should be enough in practice.
A Linux VPS running a Node app is unlikely to even have Java installed. It's a pretty big dependency and you couldn't miss it.
A Linux VPS running a Node app is unlikely to even have Java installed. It's a pretty big dependency and you couldn't miss it.
It seems like it would be easy to miss if it's in a docker container. Would auditing my docker containers be a good idea?
Also, is there a good command to run to reliably check if Java is installed on a system?
Also, is there a good command to run to reliably check if Java is installed on a system?
> Would auditing my docker containers be a good idea
Yes! I frequently review any containers from the cloud I run. Load on isolated VM, start, cursory inspection at least. Then with images I'm happy with we keep them internally, until we need the upgrade.
Yes! I frequently review any containers from the cloud I run. Load on isolated VM, start, cursory inspection at least. Then with images I'm happy with we keep them internally, until we need the upgrade.
May I suggest you look into grype[0], or some other similar tool? It can be used to scan images for vulnerabilities. You'll probably find a bunch of vulnerabilities that aren't likely to actually affect you, but still, at least you'll know they're in the images you're running. And maybe you'll start using things like docker-slim[1] on your own images to get rid of those vulnerabilities you do find.
[0]: https://github.com/anchore/grype
[1]: https://github.com/docker-slim/docker-slim
[0]: https://github.com/anchore/grype
[1]: https://github.com/docker-slim/docker-slim
No. The JAR could be inside a WAR inside an EAR.
Not to MAR the point you're making, but isn't that scenario pretty FAR from real-world PAR? I'm sure you find JARs in RARs and TARs too, especially from shady VARs, but at some point we're planning out SAR for when a meteor hits our CAR.
This tool will recursively unpack wars and ears.
I ran this on my Mac and it found 2 instances of log4j jar files, both related to Xcode:
/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar
/System/Volumes/Data/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar
Should I just delete them or is there a different mitigation? Apple needs to ship a patched Xcode version ASAP.
/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar
/System/Volumes/Data/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar
Should I just delete them or is there a different mitigation? Apple needs to ship a patched Xcode version ASAP.
See the Xcode 13.2.1 release notes [0]:
> Xcode contains a copy of the log4j library that has the CVE-2021-44228 security vulnerability. Xcode automatically downloads an updated version of this library and installs it into ~/Library/Caches/com.apple.amp.itmstransporter. When submitting apps to the App Store, Xcode uses the updated version of the library. (86390060)
[0] https://developer.apple.com/documentation/xcode-release-note...
> Xcode contains a copy of the log4j library that has the CVE-2021-44228 security vulnerability. Xcode automatically downloads an updated version of this library and installs it into ~/Library/Caches/com.apple.amp.itmstransporter. When submitting apps to the App Store, Xcode uses the updated version of the library. (86390060)
[0] https://developer.apple.com/documentation/xcode-release-note...
You can also use the --rewrite flag to automatically patch those files. This will remove the class that leads to the vulnerability and is generally a safe change.
It's odd to me that there isn't some general purpose utility that can be tweaked to search for X files and apply Y logic to it. Find on Linux kind of meets that goal kludgy as it is.
The log4j library is in a jar file. Jars files are like zip files and can contain other jar files. They can be nested arbitrarily deep. Doing a ‘find’ for a specific file name is not enough.
Point taken on the deep nesting.
find without something more won’t look inside archive files. Might be able to do something with find and zgrep.
Log4shell, that's the name of the exploit.
Considering the amount of people talking about it almost seems no one know its name.
Anyone know about issues with the log4net.dll? Last major version was 2.0.14, so it wouldn't have the fixes.
Entirely different software. Doesn't share this issue.
I think it would have been easier for them to use goreleaser[1] instead of their customized build-release.sh, release.sh system.
[1] https://github.com/goreleaser/goreleaser
[1] https://github.com/goreleaser/goreleaser
Didn't know log4js needed a canner? (Ok, couldn't help it)