Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

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.

FOLIO is not affected by the remote code execution (RCE) attack using JDBC Appender (CVE-2021-44832).

Advisories of the Log4j project: https://logging.apache.org/log4j/2.x/security.html

...

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.

Okapi doesn't protect the edge-* modules, edge-* modules that might be affected need to upgrade to log4j >= 2.17.0.

Hot-fix preview

Sysops that don't want to wait for the official hot-fix release can install the module versions of the platform-complete branch:

...

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

...

Are Kafka and Zookeeper affected?

No, because they use log4j 1.x and FOLIO doesn't set the JMS configuration TopicBindingName or TopicConnectionFactoryBindingName. For details see https://kafka.apache.org/cve-list and https://issues.apache.org/jira/browse/ZOOKEEPER-4423

...

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.

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, as patched in 2.17.1, ) that can only be triggered through malicious configuration files; since these are hardcoded 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.  Therefore, per Julian Ladisch, updating to 2.17.1 is not necessarySysop permissions are needed to set the -Dlog4j.configurationFile system property; a search through the source code shows that no FOLIO module (re)configures log4j using code (programmatic APIsetConfigLocation) and therefore cannot be (re)configured at runtime without sysop permissions.

Each edge-* module must upgrade to log4j >= 2.17.0 unless you know that it doesn't use MDC lookups.

...

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.

...