CVE-2021-44228 & CVE-2021-45046 (Elasticsearch Users be aware)

Technical assistance
1

Hello,

most of Zammad instances make use of Elasticsearch.
Please note that a 0day appeared in log4j-* modules (Java) which indirectly may affect Elasticsearch.

Learn more about CVE-2021-44228

The current suggested workaround is to create a new file nolog4j0day.options within /etc/elasticsearch/jvm.options.d/ that contains the following string

-Dlog4j2.formatMsgNoLookups=true

Don’t forget restarting your Elasticsearch service.
Please note that the workaround may be different for docker users.

Update

Application and source code users:

Please update your Elasticsearch version to 7.16.1 if not done already.
According to Elastic this version is no longer affected by log4j.

Don’t forget the attachment plugin-reinstallation hint hint.
Above provided workaround is no longer required.

docker-compose users

Please update to compose tag 5.0.3-7 or later.
Starting 5.0.3-7 the Elasticsearch version being used is 7.16.1.

helm-chart users

Helm-chart version zammad-6.0.2 contains Zammad 5.0.3 together with Elasticsearch 7.16.1.
Please update to the latest possible helm-chart version as soon as possible.

Commit reference

6 Likes
3

Hi,

is there any suggestion how to deal with Zammad running as docker-compose according to Install with Docker Compose — Zammad documentation ?

4

Try the following steps:

# Connect to your Zammad server
ssh myuser@myzammadserver -i ~/.ssh/mysshkey

# Go to Zammad folder
cd /opt/zammad

## create a file INSIDE the running elasticsearch docker container in /usr/share/elasticsearch/config/jvm.options.d/nolog4j0day.options
docker exec zammad_zammad-elasticsearch_1 bash -c "echo '-Dlog4j2.formatMsgNoLookups=true' > /usr/share/elasticsearch/config/jvm.options.d/nolog4j0day.options"

# restart ES Service
docker-compose stop zammad-elasticsearch
docker-compose start zammad-elasticsearch

## Verify that formatMsgNoLookups=true is in the output
ps auxfww | grep formatMsgNoLookups=true
1 Like
5

Hi,

I just used this (for now):

  zammad-elasticsearch:
    environment:
      - discovery.type=single-node
      - "ES_JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true"
    image: ${IMAGE_REPO}:zammad-elasticsearch${VERSION}
    restart: ${RESTART}
    volumes:
      - elasticsearch-data:/usr/share/elasticsearch/data
6

i use zammand 3.6.0 in Docker how can I Update to a new Version?

i have installed it by docker-compose?

7

check the ‘incomplete’ docu.
https://docs.zammad.org/en/latest/install/update.html
tl;dr:

$ docker-compose stop
$ git pull
$ docker-compose pull
$ docker-compose up
8

Also, more crucial, heads up to the readme:

Please also do not hijack this thread with update questions, as this is a complete different topic from the original thread ones.

1 Like
9

I read that this would override all Java Options. So you should be careful, that you do not accidentally remove other default options.

image
image746×186 15.4 KB

I think the approach with the .options-file /jvm.options.d/nolog4j0day.options is additive: options are added to existing defaults.
But maybe Zammad people can clarify.

1 Like
10

btw by now Elastic noted that Elasticsearch 6.8.x and 7.2+ are not affected by above noted CVE.
Above mentioned steps and workarounds may still be a safety measure for your better sleep.

It has no negative effect on your Zammad instance together with Elasticsearch.

3 Likes
11

@MrGeneration Thanks for your heads up here like usual :smiley:
But please update the mitigation hint to check JVM option at runtime.
On Ubuntu /etc/elasticsearch/jvm.options.d/ might not work!

12

The workaround is now included in the 7.16.1 release, packages and docker images already available:

Users may upgrade to Elasticsearch 7.16.1 27 or 6.8.21 16, which were released on December 13, 2021. These releases do not upgrade the Log4j package, but mitigate the vulnerability by setting the JVM option 2.3k -Dlog4j2.formatMsgNoLookups=true and remove the vulnerable JndiLookup class from the Log4j package.

but beware on that one:

Note: In both of these scenarios, some vulnerability scanners may continue to flag Elasticsearch in association with this vulnerability based on the Log4j version alone. However, any of the above mitigations sufficiently protect both remote code execution and information leakage.

source: Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 - Security Announcements - Discuss the Elastic Stack

13

On my instance, jvm.options.d is a file, not a directory, so I can’t create a new file inside.
I’ve updated Elasticsearch to 7.16.1 though. This should at least partially fix the problem according to this thread: Zero-day-exploit in log4j2 which is part of elasticsearch - Elasticsearch - Discuss the Elastic Stack

Good info! This clears things up.

14

Elasticsearch is now available in version 7.16.1 in all repos (last state as per yesterday night).
Please see my first post on more input on all versions.

I’ll update this thread again as soon as we have helm-chart users covered as well.

2 Likes
15

Thanks to monotek the helm-chart is now updated as well.
With this the log4j topic is through for me. :-*

16

What exactly does that mean? How would one do the plugin-reinstallation on docker-compose?

17

Please have a look at the dividing headers.
This hint does not affect helm-chart and docker-compose.

Unless you ever had to install the ingest-attachment plugins yourself.

18

sorry my bad. Thanks!

19

Do you know if ES 7.16.1 is compatible with older version of zammad like 3.x, 4.x ? Because according to this page, it is not the case Software — Zammad System Documentation documentation

20

The documentation and the supported ES versions are up to date and thus not lying to you.

We’re talking about ES security updates and you want to ignore Zammad security issues on that regard? Why not update to a current Zammad 5.0.3 to get the desired ES support and fix all known security issues?