UPDATED 12/20/21
Quick update to say that Graylog (and elastic), in their default configuration, are not vulnerable to the dos issue that was addressed in the Log4j 2.17.0 release on 12/19/21. No mitigating actions are necessary.
UPDATED 12/16/21
Graylog has just issued new releases for versions 3.3.x – 4.2.x. These releases include an update to Log4j v2.16.0 to fix an additional security issue in Log4j that Apache disclosed to the public on December 14.
Once again, the Graylog development team immediately incorporated this fix into all supported versions of the platform as well as the Graylog Forwarder (v3.3.16, v4.0.15, v4.1.10, and v4.2.4). We recommend that all Graylog customers immediately upgrade to the appropriate version. We have also updated Graylog Cloud.
IMPORTANT – PLEASE READ
Because all versions of Graylog do not support Elasticsearch versions higher that 7.10.x, to mitigate the risk of vulnerability, you need to manually edit the jvm.options.d file. For instructions on how to do this, please refer to the steps in Elastic’s Setting JVM Options chapter. You can also find more detailed information on how to upgrade your platform and forwarder in the Graylog documentation.
The links below will take you to the Graylog updates for all supported versions of Graylog.
GRAYLOG FORWARDER
Tarball (manual installation):
OS Packages
POSTED 12/10/21
A zero-day vulnerability impacting version 2.0 <= 2.14.1 of the Apache Log4j 2 package was disclosed to the public on December 9.
Graylog uses the Log4j 2 Java library to record its own log information. Versions of this library earlier than 2.15.0 are vulnerable to a remote code execution attack, specifically when specially crafted values sent as user input will be logged by Graylog. For more details on the vulnerability, please refer to the CVE.
Apache has released a new Log4j to fix the vulnerability and the Graylog development team immediately incorporated this fix into all supported versions of the platform (v3.3.15, v4.0.14, v4.1.9, and v4.2.3).
The links below will take you to the Graylog updates for all supported versions of Graylog.
We recommend that all Graylog customers immediately upgrade to the appropriate version. We have also updated Graylog Cloud.
AFFECTED GRAYLOG VERSIONS
All versions >= 1.2.0 and <= 4.2.2.
IF YOU ARE UNABLE TO UPGRADE/YOU ARE RUNNING A VERSION EARLIER THAN 3.3
Suppose you can’t update your Graylog platform immediately or run an unsupported version of Graylog. In that case, you can mitigate the zero-day exploit by applying a change to the Graylog startup configuration.
The -Dlog4j2.formatMsgNoLookups=true Java system property can be configured to disable the vulnerable feature of the Log4j 2 library.
UPGRADING GRAYLOG
OPERATING SYSTEM PACKAGES
If you install Graylog via operating system packages, you need to update to the following package versions.
- 3.3.14-2
- 4.0.13-2
- 4.1.8-2
- 4.2.2-2
The packages still use the affected Log4j 2 library version but the -Dlog4j2.formatMsgNoLookups=true configuration setting has been applied to the default configuration.
If you do not use the default configuration of the operating system packages, you need to add the -Dlog4j2.formatMsgNoLookups=true system property to the GRAYLOG_SERVER_JAVA_OPTS variable in following files.
- DEB: /etc/default/graylog-server
- RPM: /etc/sysconfig/graylog-server
DOCKER CONTAINERS
NOTE: As of 12/16/21, if you are upgrading to the latest versions (3.3.16, 4.0.15, 4.1.10, 4.2.4) you no longer need to do anything with your Docker compose file.
If you can’t update your Docker containers to one of the fixed versions, your next step depends on whether or not you’ve configured your container.
If you HAVE configured your Docker Container, you will need to change the GRAYLOG_SERVER_JAVA_OPTS environment variable.
If you HAVE NOT configured your Docker Container, you will need to use the GRAYLOG_SERVER_JAVA_OPTS environment variable.
Example:
docker run -e GRAYLOG_SERVER_JAVA_OPTS=”-Dlog4j2.formatMsgNoLookups=true” graylog/graylog:4.2
GRAYLOG AND MONGODB
Regarding Elasticsearch and MongoDB–Graylog does not maintain these platforms, these are not maintained by Graylog we can advise that Elasticsearch and MongoDB have published advice as follows –
7.10
MONGODB
The good news is that MongoDB is not affected by the Log4j 2 vulnerability.
For more detail, click here.
ELASTICSEARCH
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.
For more detail, click here.
SOLUTIONS AND MITIGATIONS
Set the JVM option 1.3k -Dlog4j2.formatMsgNoLookups=true
For instructions on setting JVM configuration, see Elastic Advanced Configuration Guide.
FURTHER READING
If you’re looking for details on the ApacheLog4j vulnerability, here you go:
