Our great sponsors
-
Apache Log4j 2
Apache Log4j 2 is a versatile, feature-rich, efficient logging API and backend for Java.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
tsunami-security-scanner-plugins
This project aims to provide a central repository for many useful Tsunami Security Scanner plugins.
-
nuclei-templates
Community curated list of templates for the nuclei engine to find security vulnerabilities.
-
tsunami-security-scanner
Tsunami is a general purpose network security scanner with an extensible plugin system for detecting high severity vulnerabilities with high confidence.
-
semgrep
Lightweight static analysis for many languages. Find bug variants with patterns that look like source code.
-
FizzBuzz Enterprise Edition
FizzBuzz Enterprise Edition is a no-nonsense implementation of FizzBuzz made by serious businessmen for serious business purposes.
-
go-cache
An in-memory key:value store/cache (similar to Memcached) library for Go, suitable for single-machine applications.
-
lunasec
LunaSec - Dependency Security Scanner that automatically notifies you about vulnerabilities like Log4Shell or node-ipc in your Pull Requests and Builds. Protect yourself in 30 seconds with the LunaTrace GitHub App: https://github.com/marketplace/lunatrace-by-lunasec/
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
The method responsible for variable substitution is here [1].
There are other lookup mechanisms, (didn't check them all) but they only retrieve environment/static values (this one [2] for example retrieves kubernetes attributes). I think the jndi one is the only one that load and execute code.
From the documentation [3], I have the impression that these lookup are evaluated only when loading the pattern layout configuration. But in reality they are also evaluated when formatting the final log message (log.info(...)).
I agree that the input should be sanitized but only if the formatting behavior is a bug and was not intentional.
One possible explanation for the current situation, is that developers assumed that all lookup mechanism will retrieve only static values (env variables for example).
And then another dev introduced the jndi lookup which execute code, but no one noticed the impact on the already existing behavior (evaluation variable when formatting the final msg).
1: https://github.com/apache/logging-log4j2/blob/9df31f73b62ba2...
2: https://github.com/apache/logging-log4j2/blob/c2b07e37995004...
3: https://logging.apache.org/log4j/2.x/manual/lookups.html
Note that the formatMsgNoLookups workaround only applies to recent versions of the log4j library, while it's still unclear how far back this bug may stretch. Other options for patching are detailed in the thread: https://github.com/apache/logging-log4j2/pull/608#issuecomme... mentions that just removing the class providing the vulnerable behavior works well, and https://github.com/Glavo/log4j-patch is a JAR that you can add to your classpath to simply override the same class.
See https://github.com/apache/logging-log4j2/pull/608#issuecomme... for more details.
Apache Logback has an interesting commit[1]: "disassociate logback from log4j 2.x as much as possible".
They also updated their landing page [2]: "Logback is intended as a successor to the popular log4j project, picking up where log4j 1.x leaves off. Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities."
Can't say I blame them.
[1] https://github.com/qos-ch/logback/commit/b810c115e363081afc7...
[2] http://logback.qos.ch/
The trustURLCodebase check was added to the LDAP provider in 2009:
https://github.com/openjdk/jdk8u/commit/006e84fc77a582552e71...
This change is included in tag jdk8-b01, which was the first release build of Java 8.
I don't think this exploit as described actually works against a default-configured JVM released any time in the last decade. Is there actually an executable PoC which shows otherwise?
Now, it's true there are ways to exploit deserialisation without loading code. You need to find a class in the classpath that does something sketchy when deserialised. There has been a lot of work to clean up such things in recent years, but it's possible some still exist. Again, i would like to see a PoC.
Are there any mitigations in recent JVMs?
I tried reproducing this, and got the POC to hit the LDAP server, but it wouldn't load the test payload.
See also:
- https://github.com/tangxiaofeng7/apache-log4j-poc
- https://github.com/veracode-research/rogue-jndi
Minecraft servers were being actively exploited according to various tweets.
If you'd like to detect whether you're affected by this dynamically, it looks like https://github.com/google/tsunami-security-scanner-plugins/i... will eventually make it into Google's dynamic scanner:
https://github.com/google/tsunami-security-scanner (I bet it would be easy to write a plugin for https://github.com/projectdiscovery/nuclei as well.)
To see if there are injection points statically, I work on a tool (https://github.com/returntocorp/semgrep) that someone else already wrote a check with: https://twitter.com/lapt0r/status/1469096944047779845 or look for the mitigation with `semgrep -e '$LOGGER.formatMsgNoLookups(true)' --lang java`. For the mitigation, the string should be unique enough that just ripgrep works well too.
https://github.com/google/tsunami-security-scanner (I bet it would be easy to write a plugin for https://github.com/projectdiscovery/nuclei as well.)
To see if there are injection points statically, I work on a tool (https://github.com/returntocorp/semgrep) that someone else already wrote a check with: https://twitter.com/lapt0r/status/1469096944047779845 or look for the mitigation with `semgrep -e '$LOGGER.formatMsgNoLookups(true)' --lang java`. For the mitigation, the string should be unique enough that just ripgrep works well too.
https://github.com/google/tsunami-security-scanner (I bet it would be easy to write a plugin for https://github.com/projectdiscovery/nuclei as well.)
To see if there are injection points statically, I work on a tool (https://github.com/returntocorp/semgrep) that someone else already wrote a check with: https://twitter.com/lapt0r/status/1469096944047779845 or look for the mitigation with `semgrep -e '$LOGGER.formatMsgNoLookups(true)' --lang java`. For the mitigation, the string should be unique enough that just ripgrep works well too.
176K LOC. For a logging library? Oh! It's for Java. It all makes sense now.
(Yes, I've written in Java, and, of course, I used log4j in the project.)
Just reminds me of this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
> when they went a year without a release.
Cause these libraries depend on other libraries that are probably extremely out of date at that point and have their own security vulnerabilities.
An example of a project that hasn't been dismissed as "abandoned", is https://github.com/patrickmn/go-cache because it explicitly doesnt have dependencies.
So yeah, if you have a semi-complex library, a year without a release is abandoned.
The post has been partially updated to log4j2 [0] (the import is still log4j1, but I imagine this will be updated soon).
And yes, I'm actually not sure log4j1 is vulnerable. I assumed it was because the sample code in the post was using log4j1, though the description only explicitly mentions log4j2.
[0]: https://github.com/lunasec-io/lunasec/pull/270
Out of the box (at least on my text 1.8 JVM): corbaname, dns, iiop, iiopname, ldap, ldaps, rmi
For full details of how this works, use a vulnerable log4j version, log a simple (bad) lookup, and step through with a debugger for a while.
Sources:
* https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share...