And Another (Third) Log4J Issue
Apache has once again updated Log4j, this time to version 2.17. The newest version of the logging library fixes a high-severity denial-of-service issue. The vulnerability affects all versions of Log4j from 2.0-beta9 through 2.16.0. Last week, the US Cybersecurity and Infrastructure Security Agency (CISA) directed federal agencies to patch systems or apply mitigations by Friday, December 24.
As of this week, if you run Java 8, log4j 2.17.0 is the latest version fixing all known issues. For Java 7, log4j 2.12.2 should be used. As mentioned before: Keep good notes. You will have to do this again in the near future. log4j 2.15 fixes most issues, and the vulnerabilities in 2.15/16 are only exploitable if the logging configuration uses a non-default pattern layout with a context lookup. If there are critical systems still running log4j < 2.15: Patch them first before you redo the systems already at 2.15.
This is an infinite recursion bug. Essentially the function keeps being called until the host runs out of resources. I’m having flashbacks to recursive programming in college, and these are a bugger. You can either deploy Log4j 2.17, or you can change your code. The choices are to replace context lookups with thread context map patterns or remove context lookups where they originate from sources external to the application. Hint: deploy Log4j 2.17.
As more focus is given to log4j, we expect other vulnerabilities to surface. Now that you have an inventory and understanding of your attack surface as it relates to log4j, apply the patches in a cadence that matches your threat model and risk appetite.
Read more in
Bleeping Computer: Upgraded to log4j 2.16? Surprise, there's a 2.17 fixing DoS
Gov Infosecurity: Time to Patch Log4j Again; Apache Releases 2.17 Fixing DoS