Last week, a critical vulnerability was disclosed in log4j (CVE-2021-44228) [1][2]. Log4j is a very popular logging library for Java and is therefore used in many Java libraries, frameworks and applications. Even Ingenuity, the Helicopter on Mars uses Log4j!
Because Log4j is so popular, it means that the amount of applications susceptible to the security vulnerability is probably also very large. At the moment, no one has a good idea which applications are susceptible now, but the Dutch government’s National Cyber Security Center is doing an inventory [3].
THE SECURITY PROBLEM
The security problem involves remote execution of arbitrary code (also called Remote Code Execution). With a simple string (e.g., “${jndi:ldap://127.0.0.1:1389/a}”), a person can already perform the attack using template injection [4]. The impact of this security problem is very high, because it often allows a malicious person to take over the server (to install ransomware there, for example, or request information you are not supposed to access). Because log4j can be used differently for each application, how it can be misused will also vary for each application. Currently, proof of concepts already exist that demonstrate how to exploit the security problem (for products from Elastic, Apache, VMWare, RedHat, etc.).
SOLVE THE PROBLEM
Since many software vendors have not yet released an update to their software, the question now is what can you do against this security vulnerability? There are a few patch options that can limit the impact until updates come out for these products. Here, updating to the latest version is always preferred, but if this is not immediately possible there are still the following ways:
UPGRADE TO LOG4J 2.17.0
In this, the problem is solved
LOG4J 2.10.0 – 2.14.2
Set System Property log4j2.formatMsgNoLookups to true
Environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS set to true
LOG4J 2.0-BETA9 – 2.10.0
org/apache/logging/log4j/core/lookup/JndiLookup.class remove the classpath. This is possible with this handy one-liner:
Setting the log4j2.formatMsgNoLookups property is also advised as a temporary mitigation by the NCSC [2]. In addition, updating to Java JDK 6u211, 7u201, 8u191, and 11.0.1 or higher (>=12) may also partially help, but this does not protect in all cases [1]. Indeed, when updating to the latest JDK version, the com.sun.jndi.ldap.object.trustURLCodebase property is set to false by default, but it is still possible in some cases to get remote code execution via Log4j. By the way, Log4j version 1 does not contain this particular security vulnerability, but there other security vulnerabilities are known, and also advised to update.
The preference is still to update, the mitigations are a temporary solution. For Java applications being developed in-house, it is recommended to upgrade to Log4j version >= 2.17.0 as soon as possible.
[1] https://www.lunasec.io/docs/blog/log4j-zero-day/
[2] https://nvd.nist.gov/vuln/detail/CVE-2021-44228
[3] https://ncsc.nl/actueel/nieuws/2021/december/12/kwetsbare-log4j-applicaties-en-te-nemen-stappen
[4] https://issues.apache.org/jira/browse/LOG4J2-3202
