DECEMBER 10, 2021 19:29 GMT
update We’ve published a follow-up advisory with updated detail and recommended guidance.
A high-severity zero-day has been uncovered in Apache Log4j, a logging library for Java applications that’s used by countless service application architectures. PoC exploit code has already been posted on Github. Administrators of application infrastructure utilizing Log4j should take steps to patch their versions of Log4j immediately.
What’s the nature of the vulnerability?
“Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against an application.”[1]
Log4j 2 is a widely used Java logging library from the Apache Software Foundation, developers of the ubiquitous HTTP server as well as other popular open source projects like Struts, Solr, Druid, and Flink. It is very common in enterprise and cloud-based Java client-server applications.
Arguably the highest profile usage, and the reason this vulnerability surfaced, is the game Minecraft from Swedish developer Mojang Studios. They are advising users to restart their Java-based clients from the Minecraft launcher to upgrade to version 1.18.1. But the vulnerability has far-reaching scope outside the gaming world, affecting all Java runtimes that utilize Log4j.
Tracked as CVE-2021-44228, the vulnerability allows unauthenticated remote code execution. Poorly-sanitized user input logged to Log4j can be executed by the Java Naming and Directory Interface (JNDI), an API that provides convenient access to data resources for applications. Basically, any arbitrary code embedded in messages in chat or forum posts or any other type of user-submitted data can be made to execute on a vulnerable server.
Proof of concept exploit code has been published on Github.
What’s the risk?
The vulnerability is rated high-severity because it exposes any data resources or applications running on an affected endpoint. The possibilities are endless for scenarios that include users connecting to compromised servers and potentially receiving malicious payloads.
The ubiquity of Log4j 2, not unlike OpenSSL when Heartbleed was uncovered, makes this vulnerability very serious and could ultimately result in a cascade of exploits across the Internet.
Affected versions
Vulnerable Apache Log4j 2 versions:
- All versions prior to 2.15.0
1.x all versions(updated 12/13/2021)
What can I do?
Upgrade to Log4j 2.15.0.
Apache developers have added a patch to source code, available in the Log4j Github repo, but it may take time for maintainers to propagate the fix to package repositories, or application developers with packaged versions of Log4j to get updates out.
In the meantime, temporary mitigation can be accomplished by making a configuration change to parameters of the Java Virtual Machine (JVM) hosting the application which prevent poisoned logs from executing code.
Configuration should set the following parameter to true:
log4j2.formatMsgNoLookups;This can be accomplished by supplying ‐Dlog4j2.formatMsgNoLookups=True as an argument when starting the JVM via command line.
The JndiLookup class can also be removed from the classpath.
If you’re using a 1.x version of Log4j, there is a migration guide to upgrading.
Resources
- Github Advisory
https://github.com/advisories/GHSA-jfh8-c2jp-5v3q - Randori Advisory
https://www.randori.com/blog/cve-2021-44228/
