On December 10th 2021 the news about a discovered vulnerability in the highly popular Log4j project has shaken up the IT world (and beyond).
The vulnerability is tracked as CVE-2021-44228 and allows the unauthenticated, remote code execution on any application that uses Log4j version 2.0-beta9 up to 2.14.1. This bug scores 10 out of 10, the highest severity.
more information: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Enormous impact
“An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled,” the Apache Foundation said in an advisory. “From Log4j 2.15.0, this behavior has been disabled by default.”
“The Apache Log4j zero-day vulnerability is probably the most critical vulnerability we have seen this year,” said Bharat Jogi, senior manager of vulnerabilities and signatures at Qualys. “Log4j is a ubiquitous library used by millions of Java applications for logging error messages. This vulnerability is trivial to exploit.”
Who is affected
That is the real question many CISOs, System administrators, developers, and many others ask themselves. Unfortunately, that question is not easy to answer. Even if you don’t use Log4j in your own applications, there is a very high chance that you use software that runs Log4j.
To check whether your application is likely affected you must verify:
- Log4j version – all 2.x versions before 2.15.0 (released today, Friday, December 10, 2021) are affected
- JVM version – if lower than:
- Java 6 – 6u212
- Java 7 – 7u202
- Java 8 – 8u192
- Java 11 – 11.0.2
Many software projects are working hard to get the fix implemented as fast as possible, but the running software needs to be patched as well.
Software Bill of Materials are required
It’s crucial to have an inventory of used and deployed software and the best would be a complete Software Bill of Materials (SBOM) that could be queried and links the location with the dependencies. Query results are available in a few seconds.
Codenotary Cloud gives you all the tools to create, track and query your software including the SBOMs. As everything is stored tamper-proof, an attacker cannot manipulate the SBOM result!
Running applications can be affected
There is a very good blog post that covers the difficulty to find log4j not just in the source code but also in the application or running container.
Codenotary helps here as well, as the Software Bill of Materials can be created and linked for running container as well. Example running Docker container:
Codenotary vcn detects the used dependencies and log4j is one of them:
Notarization of all the SBOMs in a continuous fashion allows to be always up to date with the source code:
and the runtime:
Remediation
Download the latest Log4j mitigated version 2.15.0 from its download page
If you can’t upgrade, follow the steps below:
- If using version log4j2.x version >=2.10 and <= 2.14.1, this behavior can be mitigated by either setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
- If using version >=2.0-beta9 and <=2.10.0, mitigation is to remove log4j’s JndiLookup class from JVM’s classpath as under:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
the Codenotary solutions
Our own solutions Codenotary Cloud and Metrics & Logs are not affected by the Log4j
