Hi Guy’s,
where can is see which Version is shipped with Graylog using the Docker Installation?
/hasturo
We’ve posted official information here, @hasturo
4 Likes
And the elasticsearch infomation will be posted here once available.
Edit: doesn’t seem MongoDB has posted anything, but I don’t believe Mongo uses Log4j natively. I believe and announcement from Mongo would be posted here.
2 Likes
From the Elasticsearch link above…
Elasticsearch announcement (ESA-2021-31)
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 183 utility was disclosed publicly via the project’s GitHub 375 on December 9, 2021. Log4j is a standard logging library used by countless Java applications including Elasticsearch.
Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager, however we are making a fix available for an information leakage attack also associated with this vulnerability. The JVM option identified below is sufficient to protect any supported Elasticsearch version against the information leakage attack. On Monday 13th December we plan to make available Elasticsearch 6.8.21 and 7.16.1 which will remove the vulnerable Log4j component and set the JVM option identified below.
Affected Versions:
Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j, as well as the Security Manager which mitigates the attack.
Solutions and Mitigations:
Users may upgrade to Elasticsearch 6.8.21 or 7.16.1 once they are released
Set the JVM option 553 -Dlog4j2.formatMsgNoLookups=true
If Elasticsearch is managed by ECK, set the JVM option in the Elasticsearch custom resource podTemplate specification 52
So it seems that anyone still using Elasticsearch 6.8 will have a patch, but 7.x requires updating to 7.16 which may be problematic. Silver lining is that elasticsearch is not susceptible to the RCE portion of this CVE, but the patch will fix the data leakage.
I see here: Graylog Update for Log4j | Graylog
that older versions of Graylog can be set to remediate this vuln 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."
How/where do you make this change in version v2.4.3?
@dscryber Hey David regarding the link that you posted above, Im currently running Graylog community version 3.3.6, should I upgrade to 3.3.15? thanks in advance for your comments
@dscryber Can someone from the cybersecurity team comment on the following?
According to Apache (Log4j – Apache Log4j Security Vulnerabilities), it appears that log4j version 2.10 and greater are the only versions that you can set the Java option (formatMsgNoLookups=true) on. Versions 2.0 through 2.9 do not support this option. After reviewing the Github commit history for graylog-server, it does not appear that graylog-server moved to a version that supports this option until 3.0.0. All 2.x builds use a log4j version <2.10, therefore per Apache, this mitigation does not apply to older Graylog versions.
Based on that, the current official information is not entirely accurate. It states that for versions older than 3.3, you can apply the mitigation, but more accurately I believe that should state “for Graylog versions 3.x and later”.
For 2.x versions, will Graylog support the other mitigation documented by Apache? That would be running the following command against the graylog.jar file: zip -q -d graylog.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
2 Likes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.