A new Log4j vulnerability was announced by the Apache Software Foundation (ASF) concurrently with updated patch. CVE-2021-45046 is rated 3.7 out of a maximum of 10 on the CVSS rating system and affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0. This includes the updated version of the log4j library that was distributed on Friday, Dec 10. In order to mitigate the newly disclosed risk, log4j 2.15.0 must be updated to 2.16.0. The new version released by ASF, 2.16.0, removes the risk of the log4j library completely by disabling the Java Naming and Directory Interface (JNDI) in log4j by default and removing all support for message lookups. Users of Java 7 are advised to upgrade to Log4j 2.12.2 by ASF when the update becomes available. ASF stated in a new security advisory that CVE-2021-45046 can be used for Denial of Service (DoS) attacks under certain conditions. In addition, there are reports that the 2.15.0 version remains vulnerable under certain conditions as well. Researchers at Lunasec have discussed these conditions to be when the Pattern Layout has been modified to include a reference to a Thread Context value. It appears that referencing Thread Context values in this way bypasses the logic for disabling JNDI lookups when formatting a message. This applies even to workarounds using log4j2.noFormatMsgLookup enabled in version 2.10 and above.
Analyst Notes
While the DoS vulnerability is not as significant, the new 2.16.0 library represents a major improvement over the 2.15.0 update due to the removal of the lookup feature that causes the original CVE-2021-44228 vulnerability. At this time, Remote Code Execution (RCE) has not been identified as possible through the new CVE-2021-45046 vulnerability, only DoS, so an appropriate inventory of vulnerable software, conducting post-exploitation detection of CVE-2021-4428, and updating libraries where possible to at least 2.15.0 remain higher priorities for most organizations. Many software vendors have integrated log4j code that cannot be directly addressed by clients, and in this case, sequestering these applications where possible, conducting egress filtering, and continuing to invest in detecting exploitation attempts remain the best alternatives. Binary Defense has published a comprehensive blog detailing recommendations on managing the log4j vulnerability:
https://www.binarydefense.com/advice-for-defenders-responding-to-the-log4j-vulnerability-cve-2021-44228/
https://www.binarydefense.com/advice-for-defenders-responding-to-the-log4j-vulnerability-cve-2021-44228/
https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
https://thehackernews.com/2021/12/second-log4j-vulnerability-cve-2021.html
https://logging.apache.org/log4j/2.x/security.html
