Page Comparison

...

Many back-end modules are affected by the Log4Shell issue, until new jar files and new docker containers with a fixed version are ready the existing back-end modules should be reconfigured with an environment variable that disables the flaw for most cases in log4j:

• LOG4J_FORMAT_MSG_NO_LOOKUPS=true
• Append -Dlog4j2.formatMsgNoLookups=true to the JAVA_OPTIONS variable

Pick one of the two options.

Example for the second option: If the existing configuration has JAVA_OPTIONS="-XX:MaxRAMPercentage=66.0" then the new configuration should be
JAVA_OPTIONS="-XX:MaxRAMPercentage=66.0 -Dlog4j2.formatMsgNoLookups=true"

SQL query to do this, posted by Lucy Menon on #sys-ops Slack channel, assuming that all modules in use already have a JAVA_OPTIONS env entry:

...

Not completely. It only limits exposure while leaving some attack vectors open. Using the configuration variables is a temporary measure for the time until patched FOLIO modules are available. Please upgrade to patched modules as soon as possible.

From:  https://logging.apache.org/log4j/2.x/security.html 

History

Older (discredited) mitigation measures

...

For modules based off of Spring Boot are vulnerable as spring-boot-starter-log4j2 includes the vulnerable version of log4j.  Spring Boot has opted not to fix this version until the next release (due for Dec 23, 2021)updated their version to 2.17.0 (as of 12/23/2021), however, this is still vulnerable and will likely not be updated till their next release.

In the meantime, you can override the variable controlling Spring Boot's log4j version through the log4j2.version property (per their instructions for Maven, as FOLIO base uses their parent POM):

<properties>
  ...
  <log4j2.version>2.17.0<1</log4j2.version>
</properties>

...

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-bom</artifactId>
        <version>2.17.0<1</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>

...

If not using the log4j-bom be sure to specify 2.17.0 1 in all of your log4j dependencies, check with mvn dependency:tree.

...

No, updating to log4j >= 2.1617.0 1 is sufficient. LOG4J_FORMAT_MSG_NO_LOOKUPS=true or -Dlog4j2.formatMsgNoLookups=true should only be used by sysops for unpatched modules as a temporary fix. Don't add them to the ModuleDescriptors or LaunchDescriptors a module ships with. For details see section "Is using configuration variables secure?" above.

...

No, updating to log4j >= 2.1617.0 1 is sufficient. 

For the time while waiting for a patched module the advice from Apache (see above) suggest that the safest thing to do may be to remove JndiLookup.class from the classpath (usually from a module's fat jar).  However, the effort to remove the class and release this stripped module is as big as updating log4j and releasing a patched module.

...