Log4Shell, a serious and widespread vulnerability in Apache's Log4j library.
At the end of last week a vulnerability in Apache's Java Log4j library was disclosed. Now generally called "Log4Shell," it's formally tracked as CVE-2021-44228. Its effects are serious, widespread, and difficult to mitigate. NIST explains, "An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled." JFrog writes, "This means that if any part of a logged string can be controlled by a remote attacker, the remote attacker gains remote code execution on the application that logged the string."
The problem lies in the lookup function, Sophos explains, (Apache describes the function and how it might be exploited in its Logging Services blog.) The vulnerability could give attackers a means of controlling a server, executing whatever code they might choose. Cygenta has a useful overview of how exploitation works. It credits researchers at Alibaba with discovering the flaw in November, then responsibly disclosing it to Apache, which is why upgrades to Log4j were out when the vulnerability was disclosed. The Wall Street Journal compares Log4Shell in scope and risk to 2014's Heartbleed vulnerability.
Widespread exploitation appears to have begun only after the vulnerability was publicly disclosed, but Cloudflare and Cisco Talos both report signs of an exploit in the wild nine days before that disclosure.
Both ESET and Fastly, to take two of the many security firms who've published recommendations, emphasize the importance of determining where the Log4Shell vulnerability exists in an organization, and of then applying the available patches. BleepingComputer offers a list of affected products along with vendor advice on mitigation, and SecurityWeek is maintaining a current list of tools and resources for defenders.
Organizations have begun their long slog through a remediation that will take months (if you follow the Wall Street Journal) or years (if you believe CRN) or "months if not years" (as in ZDNet's headline). Consensus is that Log4j won't be a simple fix. The vulnerability is easy to exploit and is close to ubiquitous as a Java logging package can be. Any organization should, first, begin by determining where the library containing Log4j is actually used, and that's not a trivial task. As Duo Security observes, "Log4j is so prevalent - utilized by millions of third-party enterprise applications, cloud services and manufacturers, including Apple, Twitter, and Tesla - that security teams may have difficulties pinpointing where the library is actually being used."