Page Comparison

FOLIO is affected by the Log4Shell security issue (CVE-2021-44228 and CVE-2021-45046) and a denial of service attack issue (CVE-2021-45105) in the log4j-core library used by many FOLIO backend modules and FOLIO's Okapi. Advisories of the Log4j project: https://logging.apache.org/log4j/2.x/security.html

This page gives advice for FOLIO installations and FOLIO developers to mitigate the risks of these issues.

...

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

...

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.

...