Skip to main content

Log4Shell Vulnerability (December 2021)

Summary

This page gives an overview of the impact of the Log4Shell security exploit on the Flowable products.

More specifically, customers using the out-of-the-box WAR distributions or Docker images are affected and are strongly advised to update to the latest releases of 19 December 2021, as the previous mitigation is now documented as insufficient.

Customers using the 'custom project' approach may be affected if defaults are overridden. See below for more detailed information.

Timeline (recent first)

  • 28 December 2021: A new vulnerability was disclosed. No new version of Flowable needed. The previous advice from 19 Dec 2021 still is valid.
  • 19 December 2021: Multiple updates of release versions made available to resolve all known log4j vulnerabilities Security fixes for Flowable 3.11, 3.10, 3.9, 3.8 and 3.7.
  • 18 December 2021: After releasing versions 3.10.7 and 3.9.11 to fix the earlier two log4j vulnerabilities, the Flowable product team became aware of a third vulnerability in log4j. This third vulnerability is rated of critical severity. Flowable product team efforts switched to providing releases that fixed all current reported vulnerabilities.
  • 16 December 2021: Version 3.11.0 of all products was released, containing the log4j version that fixes both vulnerabilities.
  • 15 December 2021: A second vulnerability in log4j was discovered. While originally classified as less severe as the previous one, the classification was later changed to a higher severity.
  • 11 December 2021: Discovery of the Log4Shell security exploit. At that time, it was described that mitigation was possible by setting certain environment variables or system properties. This has later been deemed incorrect as it left certain attack vectors open.

Latest update

Update 28 Dec 2021

A fourth vulnerability in log4j was discoverd on 28 December 2021, which was disclosed under CVE-2021-44832.

A new version of log4j, version 2.17.1, was released. However, no new versions of the Flowable products are needed. This particular vulnerability only affects the 'JDBC appender' (which allows storing logs in a relational database), which Flowable does not use in its configurations.

If you have overridden the default log4j configuration of Flowable and use the JDBC appender however, make sure to follow the mitigation steps described in the log4j security advisory:

In prior releases confirm that if the JDBC Appender is being used it is
not configured to use any protocol other than Java.

Update 19 Dec 2021

A third vulnerability in log4j was discovered on 18 December 2021, which was disclosed under CVE-2021-45105.

The Flowable product team was in the process of releasing new versions of the affected Flowable products that fix the previous two vulnerabilities when news of the new vulnerability was announced. At that time, versions 3.10.7 and 3.9.11 had already been released, containing the log4j version that fixed the first two vulnerabilities.

The Log4j team advised in a security advisory that it is strongly advised to update to a new release, log4j 2.17.0.

Furthermore, the mitigation described for earlier vulnerabilities is now considered inadequate to catch all potential attacks. Additionally, the severity of the second vulnerability has been changed from moderate to critical. While most likely the analysis of 15 December 2021 still is valid, the change of severity and certain vague statements in the security update from the log4j team are of concern.

As such, it was decided to stop the in-progress Flowable updates and to release new versions that fix all three current known vulnerabilities.

Affected products: all versions of the out-of-the-box WAR distributions and Docker images of:

  • Flowable Design
  • Flowable Control
  • Flowable Work
  • Flowable Engage

Fixed versions:

  • Flowable Design: versions 3.11.1 / 3.10.8 / 3.9.12 / 3.8.16 / 3.7.11
  • Flowable Control: versions 3.11.1 / 3.10.8 / 3.9.12 / 3.8.16 / 3.7.11
  • Flowable Work: versions 3.11.1 / 3.10.8 / 3.9.12 / 3.8.16 / 3.7.11
  • Flowable Engage: versions 3.11.1 / 3.10.8 / 3.9.12 / 3.8.16 / 3.7.11

Customers are advised to update to one of these versions immediately. The mitigation and previous security releases are no longer considered secure as they leave other attack vectors open.

Previous updates

Update 19 December 2021

All following advice is no longer valid and is retained only for historical reference purpose. The information below was valid at the time of writing, but later findings and vulnerabilities required more remediation than originally documented.

Update 16 Dec 2021

Update 19 December 2021

This advice is no longer valid and is retained only for historical reference purpose.

Version 3.11.0 of all Flowable affected products (Design/Control/Work/Engage) has been released, which includes the fixed log4j version 2.16.0.

Update 15 Dec 2021

Update 19 December 2021

This advice is no longer valid and is retained only for historical reference purpose.

On 14 Dec 2021, a second vulnerability was discovered in the log4j library which was disclosed under CVE-2021-45046.

It was found that the fix applied for the first vulnerability wasn't applied correctly in certain specific non-default configurations. Additionally, the mitigation described above is not sufficient to fix this problem.

More information is described in CVE-2021-45046 and the related security update from log4j. The latter states:

note

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, ${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.

Concretely, this means that the vulnerability could be triggered due to using a pattern layout that references a (thread) context lookup. This pattern layout is a configuration setting that defines how the logging lines are written out.

The Flowable product team have analysed the Flowable codebase and determined that Flowable products are not affected by this second vulnerability, because:

  • Flowable uses the spring-boot-log4j2-starter to add the log4j dependency.
  • The default pattern layout set in the spring-boot-log4j-starter does not use any context or MDC references.
  • The pattern layout is not overridden in any Flowable product.

The exception to this is when the pattern layout is explicitly overridden (thus overriding Flowable's default). This can, for example, have been done by:

  • Setting logging.pattern.<x> to a custom setting that includes any of the vulnerable property replacements (ctx:, %X, %mdc or %MDC).
  • Setting environment variables or system properties CONSOLE_LOG_PATTERN, FILE_LOG_PATTERN (or other <x>_PATTERN) to a custom setting that includes any of the vulnerable property replacements (ctx:, %X, %mdc or %MDC).

In these circumstances, the pattern layout needs to be changed immediately and the Flowable servers restarted.

Custom projects can upgrade to log4j version 2.16.0 to obtain the latest fix from log4j that addresses the vulnerability. The soon to be released Flowable products version 3.11.0 will also contain this log4j version.

Update 11 Dec 2021

Update 19 December 2021

This advice is no longer valid and is retained only for historical reference purpose.

A high severity vulnerability was discovered in Log4j, a widely used logging library for Java that is also used in some Flowable products. It was classified as a potential RCE (Remote Code Execution) security exploit. Customers using the out-of-the-box WAR artifacts or Docker images for Design/Control/Work/Engage are urgently advised to upgrade immediately to the latest version or apply the mitigation described below. If you use the Flowable dependencies (e.g. in a custom Maven or Gradle setup) it could be that you are affected too depending on your configuration.

The vulnerability was disclosed on 10 Dec 2021 under CVE-2021-44228.

Affected products:

  • Flowable Design default WAR distribution and Docker image version < 3.10.6
  • Flowable Control default WAR distribution and Docker image version < 3.10.6
  • Flowable Work default WAR distribution and Docker image version < 3.10.6
  • Flowable Engage default WAR distribution and Docker image version < 3.10.6

Customers not using the default out-of-the-box WAR of docker artifacts, but rather a custom Maven or Gradle project could be affected, but not necessarily. See below for more information.

As not all customers are able to upgrade to the latest 3.10.x release immediately, emergency releases of previous versions are also available.

On 11 Dec 2021, we released versions 3.7.10, 3.8.15, 3.9.10 and 3.10.6 of the Flowable products that include the latest log4j version (2.15.0) that fixes the vulnerability.

Mitigation

Update 19 December 2021

This advice is no longer valid and is retained only for historical reference purpose.

If it's not possible to upgrade immediately, the RCE exploit can be disabled by setting the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to true or pass the log4j2.formatMsgNoLookups=true as a system property. Note that this applies when using the WAR file (e.g. on a Tomcat server) or a Docker image.

Custom projects

Update 19 December 2021

This information is still valid: custom projects can be affected, but not when using the default configuration.

When not using the default WAR or Docker images (e.g. a custom Maven project) you are only affected if you have explicitly added the spring-boot-starter-log4j or log4j-core dependency to your project. A custom project will usually depend on the flowable-platform-bom, which has no direct dependencies to log4j (the Spring Boot default of Logback is used and not log4j).

For Maven, run mvn dependency:tree | grep log4j-core in the root of your project on the command line and make sure the version is 2.17.0 or higher. If not, upgrade the dependency in your configuration to at least 2.17.0. For example, when using the default Spring Boot parent starter, the upgrade is done by setting

<properties>
<log4j2.version>2.17.0</log4j2.version>
</properties>