CVE-2021-44228 (log4j) Vulnerability Discussion

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.

Severity: Critical

Base CVSS Score: 10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions Affected: all versions from 2.0-beta9 to 2.14.1

Descripton: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. 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. From log4j 2.15.0, this behavior has been disabled by default.

Mitigation: In previous releases (>=2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see Java™ SE Development Kit 8, Update 121 Release Notes) protects against RCE by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.

Credit: This issue was discovered by Chen Zhaojun of Alibaba Cloud Security Team.

This is actively being attacked in the wild.

If you have any java based applications running publicly facing, consider taking them offline or putting them behind a WAF or authentication/zero trust proxy until a fix is released or it’s confirmed the application isn’t vulnerable.

Jamf Pro self-hosted mitigation: RCE 0-day exploit found in log4j - Jamf Nation Community - 253680

TL;DR for Debian/Ubuntu installs: modify /usr/local/jss/tomcat/ROOT/WEB-INF/classes/ by adding a new line:

log4j2.formatMsgNoLookups: true

Then restart Jamf’s Tomcat:
systemctl stop jamf.tomcat8
systemctl start jamf.tomcat8