I configure my Log4j with an XML file. Where should I add the formatMsgNoLookups=true?
<?xml version="1.0" encoding="UTF-8"?>
<!-- Upload files compare config -->
<configuration status="OFF">
<appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="%d{HH:mm:ss} %p - %msg%n"/>
</Console>
<!-- http://logging.apache.org/log4j/2.x/manual/appenders.html#RollingFileAppender -->
<RollingFile name="File" fileName="logs/MyLogFile.log"
filePattern="logs/MyLogFile-%d{yyyy-MM-dd}.log"
ignoreExceptions="false">
<PatternLayout>
<Pattern>%d %p %c{1.} %m%n</Pattern>
</PatternLayout>
</RollingFile>
</appenders>
<Loggers>
<Root level="INFO">
<AppenderRef ref="File"/>
<AppenderRef ref="Console"/>
</Root>
</Loggers>
</configuration>
As DuncG commented, the option to disable lookups for Log4j is not a configuration option but a system property
log4j2.formatMsgNoLookups
Depending on your environment (Spring, stand-alone executable, Tomcat web application,…) the way system properties are set may vary. The simplest possibility for starting a Java process from a JAR file would be to add
-Dlog4j2.formatMsgNoLookups=true
to your command line:
java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar
CVE-2021-44228 Log4Shell Vulnerability
If you can, upgrade to Log4j2 + Java versions as recommended by the security details on the Apache logging site. This site has changed since my original post; always follow recommended guidelines from the Apache website.
The Apache site previously suggested some workarounds for the JNDI lookup vulnerability reported against earlier releases of Log4j2.
IMO: This is such a serious vulnerability, you shouldn't contemplate these workarounds, and by the time you read this they may not help anyway. Upgrade Log4j JAR files and see the note below on places to check.
log4j2.formatMsgNoLookups
when you launch the VM, passing as
java -Dlog4j2.formatMsgNoLookups=true ...
.LOG4J_FORMAT_MSG_NO_LOOKUPS
to true.org/apache/logging/log4j/core/lookup/JndiLookup.class
from the classpath - see log4j-core-*.jar
.%m
by %m{nolookups}
for some versionsI could not find LOG4J_FORMAT_MSG_NO_LOOKUPS
when running a grep
on the Java source code for 2.14.0
, so it’s not clear if this helps at all.
Certain JDK releases mitigate the risks: JDK greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected due to defaults applied to LDAP lookups. Upgrade where possible.
Some places to check for Log4j use
Check which versions of Java you use are recent enough:
java -version
Scan your application release structures, app servers, development environments for possible old versions of Log4j:
find yourReleaseDir -type f -name log4j\*jar
If you are unsure about which Log4j version you have open the JAR file in a ZIP tool and view META-INF\MANIFEST.MF
- there may a line with details of the version:
Log4jReleaseVersion: A.B.C
View the running processes on each release machine to see if there are any open file handles to Log4j JAR files:
lsof | grep log4j
Also scan machines to verify the Java VM are versions you expect. This may spot more applications to work on:
ps -ef | egrep "(java|jdk)" #OR: | grep -v grep
Scan EAR and WAR archives on application servers to verify there aren’t any embedded Log4j JAR files inside a container archive. You can do this with find
and unzip
commands, or try the ShowClassVersions
class I wrote to detect Java compiler versions in this answer. This would print out names of JAR files inside WAR and EAR files:
java ShowClassVersions.java app_server_dir |grep log4j
app_server_dir/somewebapp.war => WEB-INF/lib/log4j2-core.jar
You can do this: %m{nolookups}
in the layout.
{nolookups}
is how you set the property log4j2.formatMsgNoLookups=true
within the configuration XML content.
Quoting from the Log4j source:
public static final boolean FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS = PropertiesUtil.getProperties().getBooleanProperty("log4j2.formatMsgNoLookups", false);
and its javadoc:
LOG4J2-2109 if true, MessagePatternConverter will always operate as though
%m{nolookups}
is configured.
Since:
2.10
Add the delimiter -Dlog4j2.formatMsgNoLookups=true
under the export catalina_opts
or export java_options
.
To whom use log4j-xml-config-file:
%m
by %m{nolookups}
in the PatternLayoutSystem.setProperty("log4j2.formatMsgNoLookups", "true");
Remember to always check for the latest information from the resources listed below.
CVE-2021-45105... 2.16.0 and 2.12.2 are no longer valid remediations! The current fixing versions are 2.17.0 (Java 8) and 2.12.3 (Java 7). All other Java versions have to take the stop gap approach (removing/deleting JndiLookup.class file from the log4j-core JAR.
The environment variable option is no longer considered a valid remediation or mitigation. It will technically slightly reduce the exposure of the vulnerability, but it won't actually fix anything. I outline remediation info below.
Remediation:
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
It's basically
zip
command that comes packaged with most Linux distributions by default.
zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
.zip
.zip
extension)\\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
.jar
This is fine if you only have one or two JAR files to deal with and you don't mind installing 7-Zip or you have PowerShell available to do it. However, if you have lots of JAR files, or if you don't want to install 7-Zip and don't have access to PowerShell, I created an open-source VBScript script (.vbs) that will do it for you without needing to install any additional software. Windowslog4jClassRemover
Read the README and the release notes - Release: The light is really easy to read & follow now CrazyKidJack/Windowslog4jClassRemover
There is a lot of confusion regarding the variable to use, log4j2.formatMsgNoLookups, log4j.formatMsgNoLookups, etc. Keep in mind that as indicated in PropertySource.java,
/ **
* Converts a property name string into a list of tokens. This will strip a prefix of {@code log4j},
* {@code log4j2}, {@code Log4j}, or {@code org.apache.logging.log4j}, along with separators of
* dash {@code -}, dot {@code.}, underscore {@code _}, and slash {@code /}. Tokens can also be separated
* by camel case conventions without needing a separator character in between.
*
* @param value property name
* @return the property broken into lower case tokens
* /
You can use different values for the variable, as you can check with this test code (unfortunately, you must indicate the property of the system in a static block, so to test the different options, you must comment or uncomment the different lines of the test).
package org.apache.logging.log4j.core.pattern;
import org.apache.logging.log4j.core.util.Constants;
import org.junit.Test;
import static org.junit.Assert.assertTrue;
/ **
*
* /
public class Log4jParameterTest {
static {
// Test Ok. All working
// System.setProperty ("log4j2.formatMsgNoLookups", "true");
// System.setProperty ("log4j.formatMsgNoLookups", "true");
// System.setProperty ("Log4j.formatMsgNoLookups", "true");
// System.setProperty ("org.apache.logging.log4j.formatMsgNoLookups", "true");
// System.setProperty ("log4j2-formatMsgNoLookups", "true");
// System.setProperty ("log4j2_formatMsgNoLookups", "true");
System.setProperty ("log4j2 / formatMsgNoLookups", "true");
// Test KO. All fail
// System.setProperty ("log5j2.formatMsgNoLookups", "true");
// System.setProperty ("log5j2-formatMsgNoLookups", "true");
}
@Test
public void testLookupEnabledByDefault () {
assertTrue ("Lookups deactivated", Constants.FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS);
}
}