[Upgrade to 2.17] Updated Guidance on Addressing Log4J CVEs

The Apache Software Foundation provided another update to log4j (version 2.17.0) to address a new CVE-2021-45105 on December 18th, 2021. Contrast recommends using this most secure version.

The latest 2.17.0 update is the latest, fixing the results.

• Log4j 2.16.0 is vulnerable to CVE-2021-45105, from December 16.
• Log4j 2.15.0 is vulnerable to CVE-2021-45046, from December 14.
• Log4j 2.14 and below are CVE-20210-44228 (log4shell), from December 9.

Specifically, this update fixes a Denial of Service (DoS) vulnerability in 2.16, resulting from uncontrolled self-referential recursion. While the vulnerability does not have the same significance as the previous Log4Shell RCE, the CVE is rated “High” severity with a CVSS score of 7.5. 

The fast release cycle is the combination of the Apache Software Foundation’s rapid response to resolve the issue, combined with deep worldwide attention from many security researchers looking at every patch. Contrast supports both open source developers as well as the security research communities.

What changed?

After releasing the 2.16 patch, another DoS was discovered and confirmed. According to the Apache JIRA issue on this topic, "if a string substitution is attempted for any reason on the following string, it will trigger an infinite recursion, and the application will crash." the proof-of-concept (PoC) payload looks like this:

${${::-${::-$${::-j}}}}

Recommendations:

You Must Locate Vulnerable Log4J Instances

Teams should leverage the Software Bill of Materials that tools like Contrast produce, to locate Log4J and other vulnerable libraries. These inventories provide immediate guidance on which applications are affected so that you can take action.

We recommend looking at other applications where you have not yet created an inventory. You can use a tool such as SafeLog4J to evaluate these applications.

You can simplify this action by re-using the same inventory that you have used for other log4j updates.

Once You have located your Log4j, what should you do?

Log4j2

Teams that locate Log4J2 in their applications should upgrade to version 2.17.0. Versions below this number are vulnerable to one or more serious and remotely exploitable CVEs.

For custom applications, we recommend that you update the library, rebuild, and redeploy the application

For vendor applications, obtain updated software from the vendor. If they do not have an update or you do not apply the update, your systems and their data are at high risk or remote exploitation.

Log4j1

Teams that locate Log4j1 should follow recommendations to either upgrade to log4j v2.17 or to remove the JMSAppender and SocketServer classes from the library. To do this run the following (with your version of log4j in the path):

• zip -d log4j-1.x.x.jar org/apache/log4j/net/JMSAppender.class
• zip -d log4j-1.x.x.jar org/apache/log4j/net/SocketServer.class

We Recommend Adding Detection and Protection

The common aspect of teams that were prepared to avoid a security scramble is that they had security sensors within applications. When the need to act appeared, they knew where to go and what to do. When these agents detect new custom vulnerabilities, these users know what happened, what the risk is, and how to fix the issue. These teams can remediate in a reasonable time to keep their organizations secure and avoid future security fire drills.

Consider using Contrast Assess and Protect to monitor and defend at your application layer.

What’s next:

The situation is fluid and constantly evolving. We will keep you updated as soon as we have something to share. Sign up here to get latest alerts on Log4J and monitor Apache’s page on this topic.