| Table of Contents |
|---|
...
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=trueto theJAVA_OPTIONSvariable
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 beJAVA_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
...
Modules don't need to be upgraded to log4j 2.17.1 because they are not affected by the remote code execution (RCE) attack using JDBC Appender (CVE-2021-44832) that can only be triggered through malicious configuration files; since these are hard-coded into each module, sysop permissions would be required to change them and, if an attacker has sysop permissions, they can do far more than exploit log4j. Sysop permissions are needed to inject a configuration file and/or set it via the -Dlog4j.configurationFile system property; a search through the source code shows that no FOLIO module (re)configures log4j using code (programmatic API, setConfigLocation) and therefore cannot be (re)configured at runtime without sysop permissions.
...
No, updating to log4j >= 2.16.0 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.
...