| 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 that use a vulnerable log4j version must be upgraded to >= 2.17.0, however, mod-* modules that already have upgraded to 2.16.0 don't need to upgrade to 2.17.0. Okapi protects all modules where it proxies requests to from the denial-of-service attack of CVE-2021-45105 (infinite recursion in MDC lookup evaluation) by filtering malicious values in the fields used for MDC (OKAPI-1058), therefore those modules don't need log4j 2.17.0 and can safely continue to use log4j 2.16.0. CVE-2021-44832, as patched in 2.17.1, can only be triggered through malicious configuration files; since these are hardcoded 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. Therefore, per Julian Ladisch, updating to 2.17.1 is not necessary.
Each edge-* module must upgrade to log4j >= 2.17.0 unless you know that it doesn't use MDC lookups.
...
For modules based off of Spring Boot are vulnerable as spring-boot-starter-log4j2 includes the vulnerable version of log4j. Spring Boot has 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 meantimetherefore, pulling in the newest spring-boot-starter-log4j2 should be sufficient.
In you need to specifically override the version provided by Spring Boot, you can override the variable controlling Spring Boot's log4j version through the log4j2.version property like so (per their instructions for Maven, as FOLIO base uses their parent POM):
...
Non-RMB modules might use other ways to update log4j.
If a module needs to directly sets set the version of log4j it should use the a <dependencyManagement> entry with log4j-bom to keep all log4j components (log4j-api, log4j-core, ...) in sync:
...
If not using the log4j-bom be sure to specify 2.17.1 the version in all of your log4j dependencies, check with mvn dependency:tree.
...
No, updating to log4j >= 2.1716.1 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.
...
No, updating to log4j >= 2.1716.1 0 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.
...