Clarification about CVE-2021-44228 security vulnerability

[pditommaso]

The recent security vulnerability affecting the popular Log4j logging library for Java applications raised a lot of comments in the open-source community.

Since Nextflow runs on top of the Java virtual machines some users raised concerns about this exploit and there's any s

TLDR; Nextflow is safe.

Nextflow don't use Log4j library, instead logging is done via Slf4j + Logback, as such Nextflow is not effected by CVE-2021-44228 vulnerability.

Some concerns have been raised also regarding the security of Slf4j and Logback.

• Slf4j is a mere interface API that implements a generic abstraction for application logging so that an application can delegate the actual logging to a separate implementation. As such it's not affected by the CVE-2021-44228 vulnerability.

• Logback is the actual library used by Nextflow for application logging. As reported by the author Logback is safe in respect to CVE-2021-44228 [1]. However, Logback may make JNDI calls from within its configuration file. This was recently reported in LOGBACK-1591 as a vulnerability of lesser severity compared to CVE-2021-44228.

• To be able to exploit the Logback vulnerability above the attacker should:

  • write access in the launch directory to create or modify the logback.xml config file
  • use of logback version older than 1.2.8
  • loading of poisoned configuration data, which implies application restart or scan="true" set prior to attack

• When using Nextflow these conditions cannot be fulfilled because as soon as it starts any logger eventually configured via the logback.xml file are removed, and Nextflw setup its own logging appenders. See here.

• In any case, as a pure precautionary action, the Logback library has been upgraded to the latest version 1.2.8, which addresses the security issue with JNDI calls. a957db6.

• Nextflow uses also the library log4j-over-slf4j.jar. Note that despite the name this does not represent a security issue. This library is actually a replacement for Log4j logging and allows components that depend on the Log4j APIs to redirect the logs to Lockback via Slf4j.

Further reading

1. http://slf4j.org/log4shell.html