Apache Log4j Security Vulnerabilities
Apache Log4j is a Java-based logging utility originally written by Ceki Gülcü. It is part of the Apache Logging Services and it is (widely) used worldwide across software applications and online services. With over 400,000 downloads from its GitHub repository, Apache Log4j is the most popular java logging package. Many types of enterprise and open-source software, including cloud platforms, online applications, and email services, employ ‘Apache Log4j.’
On 9 December 2021, a zero-day vulnerability involving arbitrary code execution in Log4j 2 was published by the Alibaba Cloud Security Team and given the descriptor CVE-2021-44228. The vulnerability has existed unnoticed since 2013.
What cause the vulnerability?
Log4j2 supports by default a logging feature called “Message Lookup Substitution”. This feature enables certain special strings to be replaced, at the time of logging, by other dynamically-generated strings. It has been discovered that one of the lookup methods, specifically the JNDI lookup paired with the LDAP protocol, will fetch a specified Java class from a remote source and deserialize it, executing some of the class’s code in the process. 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.
Why the vulnerability is dangerous?
The vulnerability, which received the highest CVSS score possible – 10.0 – is extremely dangerous due to a number of factors: Log4j2 is one of the most popular Java logging frameworks. There are currently almost 7,000 Maven artifacts that depend on log4j-core (the vulnerable artifact), and there are countless others Java projects that use it. The vulnerability can easily be used in a drive-by-attack scenario by bombarding random HTTP servers. Exploitation of the vulnerability is trivial and persistent, with tons of weaponized exploits available on GitHub and other public sources.
How do I fix the issue?
The best fix for this issue would be to upgrade your log4j dependencies to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later), which completely resolves the issue by disabling JNDI by default and removing support for message lookups. Alternatively, this infinite recursion issue can be mitigated in configuration:
- In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC)
- Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.
Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability. More info about the vulnerability can be found at apache.org official page.
