Where to put formatMsgNoLookups in log4j XML config file

Question

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> 

Answer 1

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.

1. Set system property log4j2.formatMsgNoLookups when you launch the VM, passing as java -Dlog4j2.formatMsgNoLookups=true ... .
2. Set environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
3. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the org/apache/logging/log4j/core/lookup/JndiLookup.class from the classpath - see log4j-core-*.jar.
4. replace format pattern %m by %m{nolookups} for some versions

I 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