Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228

Announcements
1

Camunda is aware of the Log4j security vulnerability that is currently being covered prominently in the press (e.g. Hacker News), specifically CVE-2021-44228.

Below you can find the current state of our assessment and response to this vulnerability. We are updating this statement as we learn more and release patches.

Camunda recommends all users and customers to

  • Verify whether affected versions of log4j are used in their own application code

  • Verify any additional Java-based components they are running in combination with Camunda such as application servers or elasticsearch distributions

For Camunda Platform 7 Users & Customers

Camunda Engine, Cockpit, Tasklist & RPA Bridge

Camunda Platform distributions (like WildFly, Tomcat, and Run) do not contain the vulnerable log4j-core artifact. Some distributions contain the log4j-api or log4j-to-slf4j bridge, which are not vulnerable without the log4j-core artifacts.

Camunda has released version 7.17.0-alpha2 which updates to Log4J 2.15.0. Camunda has released 7.16.3, 7.15.9, and 7.14.15 on Fri Dec 17 which updates to Log4J 2.16.0.

Camunda has released 7.14.16; 7.15.10; 7.16.4; RPA Bridge 1.1.4 on Wed Dec 23 which updates to Log4J 2.17.0 and logback 1.2.9.

Camunda plans to release version 7.17.0-alpha3 on Tue Jan 11 2022 which contains all of these fixes.

Optimize

Camunda Optimize production and docker distributions do not contain the vulnerable log4j-core artifact. Camunda Optimize production and docker distributions contain the log4j-api or log4j-to-slf4j bridge artifacts, which are not vulnerable without the log4j-core artifacts.

The Optimize demo distribution <3.6.5 bundles Elasticsearch 7.10.0. Elastic states that 7.8+ releases used with recent JDK9+ releases are not susceptible to remote code execution or information leakage.

Camunda has released Optimize 3.6.5 on Tue Dec 21 with updated Log4J 2.17.0 artifacts, as well as an updated bundled Elasticsearch 7.16.2 in the demo distribution.

Please note that Optimize 3.6.x is known to not support the Elasticseach 7.16.0 and 7.16.1 releases, due to a regression Elastic introduced with the 7.16.0 release.
Optimize 3.6.5 is verified to be compatible with the recent Elasticsearch 7.16.2 release which contains a fix for the regression introduced in 7.16.2, we thus recommend using the Elasticsearch 7.16.2 release.

Cawemo

Cawemo does not contain the vulnerable log4j-core artifact. It does bundle the log4j-api and log4j-to-slf4j bridge, which are not vulnerable without the log4j-core artifact.

Camunda has released Cawemo 1.8.3 on Wednesday Dec 15 which updates to Log4J 2.16.0.

Cawemo On-Premise depends on the IAM component so please make sure you also pull the newly released 1.1.10 IAM images.

Update 21.12.21:
Camunda has released Cawemo 1.8.4 on Tuesday Dec 21 which updates to Log4J 2.17.0 and logback 1.2.9.
Cawemo On-Premise depends on the IAM component so please make sure you also pull the newly released 1.1.11 IAM images.

For Camunda Cloud Users & Customers

Zeebe

Zeebe does contain the vulnerable log4j-core artifact. At this point, Camunda is not aware of any specific attack vector in Zeebe.

Camunda has released Camunda Cloud 1.1.7, 1.2.6 and 1.3.0-alpha3 on Tue Dec 14 updating to Log4J versions 2.15.0 and recommends an update to these versions. See Camunda Cloud Security Notices.

Camunda has released Camunda Cloud 1.1.8 and 1.2.7 on Friday Dec 17 updating to Log4J version 2.16.0. See Camunda Cloud Security Notices.

Camunda has released Camunda Cloud 1.1.9 and 1.2.8 on Wednesday Dec 22 updating to Log4J version 2.17.0. See Camunda Cloud Security Notices.

Camunda has released Camunda Cloud 1.1.10 and 1.2.9 on Friday Dec 31 updating to Log4J version 2.17.1. See Camunda Cloud Security Notices.

Operate & Cloud Tasklist

Operate & Cloud Tasklist do contain the vulnerable log4j-core artifact. At this point, Camunda is not aware of any specific attack vector in Operate or Tasklist.

Further, Operate and Cloud Tasklist also rely on elasticsearch. Elastic has released elasticsearch 7.16.1 and recommends updating to this version or setting the system property -Dlog4j2.formatMsgNoLookups=true. Camunda advises customers set this property until a version of Operate & Cloud Tasklist supporting elasticsearch 7.16.1 is available

Camunda has released Camunda Cloud 1.1.7, 1.2.6 and 1.3.0-alpha3 on Tue Dec 14 updating to Log4J versions 2.15.0 and recommends an update to these versions. See Camunda Cloud Security Notices.

Camunda has released Camunda Cloud 1.1.8 and 1.2.7 on Friday Dec 17 updating to Log4J version 2.16.0 and Elasticsearch 7.16.1.See Camunda Cloud Security Notices.

Camunda has released Camunda Cloud 1.1.9 and 1.2.8 on Wednesday Dec 22 updating to Log4J version 2.17.0 and Elasticsearch 7.16.2.See Camunda Cloud Security Notices.

Camunda has released Camunda Cloud 1.1.10 and 1.2.9 on Friday Dec 31 updating to Log4J version 2.17.1.See Camunda Cloud Security Notices.

IAM

IAM does not contain the vulnerable log4j-core artifact. It does bundle the log4j-api and log4j-to-slf4j bridge, which are not vulnerable without the log4j-core artifact.

Camunda has released IAM 1.1.9 and 1.2.6 on Tue Dec 14 which updates to Log4J versions 2.15.0 and recommends updating to this version. See Camunda Cloud Security Notices.

Camunda released IAM 1.1.10 and 1.2.7 on Friday Dec 17 updating to Log4J version 2.16.0 and logback 1.2.8. See Camunda Cloud Security Notices.

Camunda released IAM 1.1.11 and 1.2.8 on Wednesday Dec 22 updating to Log4J version 2.17.0 and logback 1.2.9. See Camunda Cloud Security Notices.

Camunda released IAM 1.1.12 and 1.2.9 on Friday Dec 31 updating to Log4J version 2.17.1. See Camunda Cloud Security Notices.

13 Likes
2
3
4
5
6

I am not able to see any Camunda docker image (Docker Hub) release with these version yet. May I know when it will be release?

7

Hi @pallabganai,

The latest alpha release Camunda Platform Runtime 7.17.0-alpha2 contains the security fixes. (please see the updated post or next comment). Patch releases are only available for enterprise customers.

Best,
Tassilo

1 Like
8

Please note that we previously mistakenly reported version 7.17.0-alpha2 to contain all security fixes mentioned in this post. It updates log4j to version 2.15.0 only. Camunda will release version 7.17.0-alpha3 on 11th of January that updates log4j to version 2.17.0 and logback to 1.2.9.

9

@tasso94,

Patch releases are only available for enterprise customers.

A security vulnerability this large and you’re not going to release the fix to the community? That’s not very friendly.

10

Hi @DGilmour22,

The next alpha release (7.17.0-alpha3) will provide updates for log4j and logback.

Best,
Tassilo

11

Just to clarify - alpha releases are always available to the community and in the past we’ve always added fixes to issues like these to the alpha releases.

12

Alpha releases are not for production, right? These are used mainly for development or testing.
There are many users, including us, who are using Camunda Community version in production.
In the current circumstance the options available for users like are limited.
(1) Deploy the Camunda Alpla version in production and deal with potential bugs in live system - risky move. No one is comfortable with that.
(2) Use the vulnerable version until a new community version is released by Camunda - very risky, not going to happen
(3) Purchase enterprise license - this disrupts the financial planning, new vendor contract signing takes time in large organizations as it need to go though number of approvals, legals. In short not going to happen.
Not in a good situation to be. Given the impact of the vulnerability, I was expecting Camunda will release an emergency 7.16.x release with the fix for community users.

1 Like
13

Hi @pallabganai
Thanks for your feedback :slight_smile:
Hopefully i can add some clarification here.

This is a better option than it might seem actually - Alpha releases will often have new features that are not yet fully complete but it will still function normally. It can also have a lot of bug fixes that the previous version (e.g 7.15.0) didn’t have.

Our alpha releases go through the same testing procedure as our minor releases so are not necessarily less stable.

If we where to release an emergency version of 7.16.0 it wouldn’t be very different at all from the alpha version with the fix that we’re releasing. it would only be an issue with the naming conversion. You would only need to use the alpha version until the 7.16.0 release proper comes out so it’ll be about 5 months but in that time you’d be protected against the Log4J2 vulnerability.

If you’re using a vulnerable component then it makes sense to move to the alpha version that has the fix. Even if you don’t have a good feeling about the alpha release, it’s likely still better than going with an unfixed one.

There are lots of good reasons a company might have for purchasing an enterprise license but it’s honestly against our core values to use a situation like this as one of those reasons.
This is why we’re working hard to get this patch into an upcoming alpha release that everyone can use. We have no interest in having our community (the vast majority of our users) suffer by being forced to use vulnerable software and certainly wouldn’t want them to feel like we don’t value their experience with the software.

This is probably already quite clear by the fact we’re not just telling people to either wait a few months for the next release OR buy a license. We’re worked to offer what i think is a really good 3rd option and as i mentioned this is something we’ve always done for high-profile bugs or security issues in the initial open source release.

-Niall

4 Likes
14
15