Dec 17 update: The CVSSv3 score for CVE-2021-45046 has been raised from 3.7 to 9.0.
While many organizations are still dealing with the discovery and mitigation process for the previous Log4j CVE, the project has announced that another vulnerability CVE-2021-45046 has been discovered due to an incomplete fix in Log4j 2.15.0. In response, a new version of Log4j (2.16.0) has been released that by default disables JNDI functionality, which was the source of the original issue.
Incomplete mitigations leave risks
Since the original vulnerability was released, there has been a panoply of suggested mitigations for use when patching is not an immediate option. Inevitably, when these mitigations are developed quickly, subsequent research has revealed that they may not be as solid as first thought.
Particularly relevant for this new CVE are mitigations that initially appeared to remediate the issue, setting formatMsgNoLookups=true when invoking Java or setting LOG4J_FORMAT_MSG_NO_LOOKUPS=true as an environment variable.
Recent research has concluded that even with these mitigations in place, older versions of Log4j may be vulnerable to remote code execution.
The additional risk noted in CVE-2021-45046 is a denial-of-service attack that can occur when Log4j 2.15.0 is in use. This is generally considered less serious than a remote code execution, however, the safest path for companies will still be to ensure that they fully upgrade to the latest Log4j version.
How Aqua can help
The detection and mitigation capabilities published for the original Log4j issues also apply to show and mitigate where Log4j 2.15.0 is an issue.
Using Trivy to detect vulnerable software libraries
Aqua’s open source scanning tool Trivy can detect and report on both the original Log4j issue (CVE-2021-44228) and this new one. Scanning a container image with a known vulnerable Log4j version will produce output like this:
Conclusion
The Log4j vulnerability has become one of the largest security issues we’ve seen in recent times. With the level of attention now being focused on this problem both by attackers and defenders, it’s likely that we’ll see further information and possible vulnerabilities.
In the aftermath of the immediate response, companies should carefully consider how they can manage this type of risk strategically. Improving detection of software versions and using software supply chain security tools are good examples of defense-in-depth security measures that can provide short-term mitigations. Using these tools gives IT departments the time needed to coordinate comprehensive patching and testing of their software systems in a safe and controlled fashion.
