Zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Where an upgrade is not immediately possible, an alternative mitigation option is to remove the JndiLookup class from the classpath: With all eyes on Log4j, vulnerability CVE-2021-44832(affecting versions 2.0-beta7 through 2.17.0) was discovered on December 29th: an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue was fixed in Log4j 2.17.0 and 2.12.3. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. As CVE-2021-45105 discovered that Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) did not protect from uncontrolled recursion from self-referential lookups. These changes are available in log4j 2.16.0. Even though the issue was fixed, the team continued the work to further harden the library by disabling the JNDI lookup by default and to disabled message lookups. Log4j 2.15.0 is already available in Maven Central and all users are encouraged to upgrade immediately where possible. The log4j contributors mobilized to ensure that a fix was available and quickly merged. As pointed out by the POC published on GitHub, when log4j logs an attacker-controlled string value it can result in a Remote Code Execution (RCE). Log4j 2.15.0 has been released, which no longer has this vulnerability.
All the library’s versions between 2.0 and 2.14.1 included are affected. On December 9th, it was made public on Twitter that a zero-day exploit had been discovered in log4j, a popular Java logging library. Please comment if something needs to be updated. This is an evolving story, we will continue updating it.
0 kommentar(er)
