| Table of Contents |
|---|
...
Okapi protects all modules where it proxies requests to (the mod-* modules) 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.
...
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.
...
RMB based modules should remove any direct log4j dependency from their pom.xml and use the log4j version provided by RMB if they want the log4j version being automatically updated when updating RMB.RMB based modules using log4j 2.16.0 and the default RMB log4j configuration literally print [${FolioLoggingContext:requestid}] [${FolioLoggingContext:tenantid}] [${FolioLoggingContext:userid}] [${FolioLoggingContext:moduleid}] into the log without replacing these variables by the values; this is only a usability issue, not a security issue. To get proper variable expansion those modules should upgrade to log4j >= 2.17.0, to avoid false positive vulnerability reports by security scanner those modules should upgrade to log4j >= 2.17.1.
Spring Boot based modules
...
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.
...