Excerpt |
---|
, last updated |
Info |
---|
This advisory was updated on to document the latest findings about log4j 1.2.17. |
The log4j 2.x security issue disclosed in CVE-2021-44228 also affects some components of the Squirro Insight Engine. Squirro includes the following three Java services which all use log4j: Elasticsearch, Zooekeeper, Tika (embedded or as a separate server).
Issue identifier: CVE-2021-44228
Products and Versions: All versions of Squirro Insights Engine
Overview
Since OpenJDK 8u191 the vulnerability seems to not be exploitable (see e.g., Rapid7). The latest Squirro versions ship with the newer 1.8.0_312, and for at least the last three years Squirro has shipped Java runtimes higher than that version.
This document includes the configuration changes required to remediate the security problems. We will update this document when we release patches and version updates that fix the issue out of the box.
We are aware that some of our components (Tika and Zookeeper) include log4j 1.2.17. A separate CVE has been created for that version (CVE-2021-4104) and this version is only vulnerable if their configuration uses the JMSAppender. Squirro’s out-of-the-box configuration does not include this appender anywhere. As a result no immediate action is required for these components.
Solution
The official CVE communication recommends setting the system property log4j2.formatMsgNoLookups=true
. Additionally you should check the JDK version.
Elasticsearch
Change Elasticsearch configuration by adding the following line to /etc/elasticsearch/jvm.options
:
Code Block |
---|
-Dlog4j2.formatMsgNoLookups=true |
Apply the changes by running:
Code Block |
---|
systemctl restart elasticsearch |
Tika service
Info |
---|
This is an optional component and is usually not yet installed. If the following file does not exist, you can safely assume that the Tika server has not been installed. |
Adjust the ExecStart
line in /usr/lib/systemd/system/tika.service
and change it to include. -Dlog4j2.formatMsgNoLookups=true
`. Depending on your Squirro version, this will change the line to:
Code Block |
---|
ExecStart=/usr/bin/java -Dlog4j2.formatMsgNoLookups=true -jar /usr/share/java/tika-server.jar |
or
Code Block |
---|
ExecStart=/usr/bin/java -Dlog4j2.formatMsgNoLookups=true -jar /usr/share/java/tika-server.jar --includeStack -c /etc/tika-config.xml |
Apply the changes by running the following two commands:
Code Block |
---|
systemctl daemon-reload
systemctl restart tika |
JDK
Check the JDK version with the following command:
Code Block |
---|
java -version |
If the version given is 1.8.0_121 or newer, the vulnerability should not be exploitable.
Web Application Firewall - WAF
If you have deployed a WAF in your environment, check with your vendor if they already include detection rules for this vulnerability. It may be worth including those rules as well for additional protection.
Support
For any further questions, please don't hesitate to contact us at support@squirro.com or on http://go.squirro.com/support. For security-related communications you can use security@squirro.com.
References
...
...
https://blog.sonatype.com/a-new-0-day-log4j-vulnerability-discovered-in-the-wild
...
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b - patterns for detecting attempted exploitations
...
https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476 - Elasticsearch announcement
...
This page can now be found at CVE-2021-44228 - log4j Security Vulnerability on the Squirro Docs site.