Question about Log4j Vulnerability CVE-2021-44228

Graylog Central (peer support)
1

Good morning,
I wanted to ask about the vulnerability in question.
I installed graylog on a linux 20.04.3 machine, I upgraded from version 4.2.2 to version 4.2.3 through the repository
By checking the folder / usr / share / elasticsearch / lib7 I see that the following libraries appear:
log4j-api-2.11.1.jar and log4j-core-2.11.1.jar

so I assume that the update to version 4.2.3 did not update the libraries to version 2.15.0 as well

Can you suggest me how to update or mitigate this vulnerability

Thanks for taking the time

This is currently my graylog-server file, maybe just edit it, can you suggest me how?

Path to the java executable.

JAVA=/usr/bin/java

Default Java options for heap and garbage collection.

GRAYLOG_SERVER_JAVA_OPTS="-Xms5g -Xmx5g -XX:NewRatio=1 -server -XX:+ResizeTLAB -XX:-OmitStackTraceInFastThrow"

Avoid endless loop with some TLSv1.3 implementations.

GRAYLOG_SERVER_JAVA_OPTS="$GRAYLOG_SERVER_JAVA_OPTS -Djdk.tls.acknowledgeCloseNotify=true"

Pass some extra args to graylog-server. (i.e. “-d” to enable debug mode)

GRAYLOG_SERVER_ARGS=""

Program that will be used to wrap the graylog-server command. Useful to

support programs like authbind.

GRAYLOG_COMMAND_WRAPPER=“authbind”

2

Hello there

Yes, Elasticsearch has a vulnerability that must be addressed seperately to Graylog (they are seperate products).

See:

Affected Versions:

Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j. We’ve confirmed that the Security Manager mitigates the remote code execution attack in Elasticsearch 6 and 7; investigation is still underway for Elasticsearch 5.

Solutions and Mitigations:

Set the JVM option 1.3k -Dlog4j2.formatMsgNoLookups=true

3

but wouldn’t it be possible to see a configuration file with the change applied without having to get lost in a thousand guides?
A simple file where the option -Dlog4j2.formatMsgNoLookups = true appears?
I have problems with English and I struggle

4

https://www.graylog.org/post/graylog-update-for-log4j
on the Graylog site it is indicated that the graylog-server file must be modified, I posted mine, must it be modified?
If so, can someone repost it with the modified / added string?
Or write a series of steps to take?
Thank you
@jan can you help me please ?
Is it enough to run the following command on 4.2.3 version ?

docker run -e GRAYLOG_SERVER_JAVA_OPTS=”-Dlog4j2.formatMsgNoLookups=true” graylog/graylog:4.2

5

ok,
problem solved.
While upgrading to version 4.2.3 I had chosen to keep the configuration file currently in use, so it hadn’t added the string:

Fix for log4j CVE-2021-44228

GRAYLOG_SERVER_JAVA_OPTS = “$ GRAYLOG_SERVER_JAVA_OPTS -Dlog4j2.formatMsgNoLookups = true”

to the graylog-server
Manually added.

6

As I read Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046) | LunaSec and Log4j – Apache Log4j Security Vulnerabilities setting the -Dlog4j2.formatMsgNoLookups = true will not solve the complete issue. and you are then still vulnerable.

7

Ok
Thanks for the report
So what would be the ultimate solution to eliminate this vulnerability on graylog?

https://nvd.nist.gov/vuln/detail/CVE-2021-45046

This problem can be mitigated in previous versions (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core - *. Jar org / apache / logging / log4j / core / lookup / JndiLookup .classe ).
Is it possible to make this setting on graylog?
Or is it possible to migrate to version 2.16.0 on graylog?

8

Hey there, new to the Graylog game :wink:
We are currently setting up our first Graylog.

Am I seeing this right, If I want to be save log4shell wise, I´d have to use a pretty old version of ES, 6.8.21 since the up todate version of ES won´t work with graylog? :confused:
Or running the 7.10 with the Java Security Manager and option to disable the lookups?

Not sure what would be the most secure way, since graylog will hold some sensible data…
Cheers

9

Will there be a further update to Graylog 3.3 with the new Log4j to address the second CVE?

10

It would be useful to be able to upgrade to version 2.16.0 of the libraries, in this way it would not be a mitigation but a real resolution of the vulnerability

11

I’d suggest to run ES 7.10 (always try to stay up to date if security is important) and disable the lookups with the aforementioned java option.

12

ES 6.8.21 also uses the security manager and their docker image runs JDK 15, all of which is meant to be immune from this vulnerability.

13

There is now a page in the Graylog docs being maintained with pertinent info on mitigating exposure to CVE-2021-44228, here:

https://docs.graylog.org/docs/upgrade-graylog-against-log4shell

This will be kept up to date with any new developmemts.

14

Hi all, best of all is to delete the jndilookup.class out of the log4j jar file, even elastic is doing so:

Good and complete story on this matter:

1 Like
15

Thank you. Will there be another update for the latest exploit fixed in log4j 2.17.0 please?

Also, the page you link doesn’t list the new docker tags for graylog itself, only elasticsearch.

16

Is it possible to just replace the log4j file in Graylog i.e unpack /repack jar? For some people they may be on versions that are not supported i.e less then 3.3

17

@tellistone

Can you configmr that the following is a fix for graylog versions less than 3.3

1.) Remove the class from the graylog .jar file.

 zip -d graylog2-server-3.3.11-shaded.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

2.) Upgrade elasticsearch-oss to 6.8.22 as per Mitigate Log4j2 / Log4Shell in Elasticsearch

Cheers

1 Like
18

Hello,

We got a vulnerability as well in graylog-collector ver 0.4.2 in RHEL 7, removing the classes is immediate remediation. Is there a new package that already patched this or upgraded the log4j to the new version?

Results of scan…
Scanning directory: / (without /dev, /dev/shm, /run, /sys/fs/cgroup, /var/lib/sitedata/prod, /run/user/18981, /run/user/0)
Running scan (10s): scanned 22574 directories, 1515665 files, last visit: /usr/lib/jvm-exports/java-1.8.0-openjdk-1.8.0.302.b08-0.el7_9.x86_64
[*] Found CVE-2021-44228 (log4j 2.x) vulnerability in /usr/share/graylog-collector/graylog-collector.jar, log4j 2.4.1

Scanned 30471 directories and 1370453 files
Found 1 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 17.80 seconds

rpm -qi graylog-collector

Name : graylog-collector
Version : 0.4.2
Release : 1
Architecture: noarch
Install Date: Fri 26 Oct 2018 03:01:30 PM NZDT
Group : optional
Size : 11335101
License : GPLv3
Signature : RSA/SHA1, Tue 05 Jan 2016 01:17:02 AM NZDT, Key ID d44c1d8db1606f22
Source RPM : graylog-collector-0.4.2-1.src.rpm
Build Date : Tue 05 Jan 2016 01:16:56 AM NZDT
Build Host : 2c345862f441
Relocations : /
Packager : Graylog, Inc. hello@graylog.org
Vendor : graylog
URL : https://www.graylog.org/
Summary : Graylog collector
Description :
Graylog collector

sudo rpm -ql graylog-collector
/etc/graylog/collector/collector.conf
/etc/graylog/collector/log4j2.xml
/etc/sysconfig/graylog-collector
/usr/lib/systemd/system/graylog-collector.service
/usr/share/graylog-collector/bin/graylog-collector
/usr/share/graylog-collector/graylog-collector-script-config.sh
/usr/share/graylog-collector/graylog-collector.jar
/usr/share/graylog-collector/lib/sigar/libsigar-amd64-linux.so
/usr/share/graylog-collector/lib/sigar/libsigar-x86-linux.so

rpm -qf /usr/share/graylog-collector/graylog-collector.jar
graylog-collector-0.4.2-1.noarch

Thanks.

19

Could we have a 3.3.17 with log4j 2.17?

20

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.