This morning, the Apache Software Foundation provided another update to log4j (version 2.17.0) to address a new CVE-2021-45105. 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.
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:
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?
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.
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.