<!-- Source: https://docs.squirro.com/en/latest/security/advisories/44228.html -->
# CVE-2021-44228 - log4j Security Vulnerability

11 Dec 2021, last updated 20 Dec 2021

Note: This advisory was updated on 20 Dec 2021 to provide an additional optional remediation step, as well as update regarding the newly discovered log4j vulnerability in CVE-2021-45105.

Note: This advisory was updated on 14 Dec 2021 to document the latest findings about log4j 1.2.17.

The log4j 2.x security issue disclosed in [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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](https://www.rapid7.com/blog/post/2021/12/10/widespread-exploitation-of-critical-remote-code-execution-in-apache-log4j/)). 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](https://access.redhat.com/security/cve/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.

Update 20 Dec 2021 : On December 16th, 2021, CVE-2021-45105 was disclosed. It describes a Denial of Services vulnerability of the log4j framework. Elasticsearch has updated its guidance and declares Elasticsearch to be not vulnerable to this issue and that the mitigations outlined below are sufficient.

Source: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476#update-december-18-5

## 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`:

```python
-Dlog4j2.formatMsgNoLookups=true
```

Apply the changes by running:

```python
systemctl restart elasticsearch
```

As an optional, secondary mitigation, the affected `JndiLookup.class` file can easily be removed from the package. This hotfix works for all versions of Elasticsearch.

Take a backup of the jar file, to enable a rollback option:

```python
tar -czf /usr/share/elasticsearch/log4j-hotfix-backup.tar.gz /usr/share/elasticsearch/lib/log4j-core-2.*
```

Install the `zip` utility if required and remove the affected `JndiLookup.class` class file from the jar file (jar files are actually zip files).

```python
yum install -y zip
zip -q -d /usr/share/elasticsearch/lib/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class
```

Apply the changes by running:

```python
systemctl restart elasticsearch
```

## Tika Service

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:

```python
ExecStart=/usr/bin/java -Dlog4j2.formatMsgNoLookups=true -jar /usr/share/java/tika-server.jar
```

or

```python
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:

```python
systemctl daemon-reload
systemctl restart tika
```

## JDK

Check the JDK version with the following command:

```python
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, visit the [Squirro Support website](https://go.squirro.com/support) and submit a technical support request. For security-related communications, contact `security@squirro.com`.

### References

- [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228)
- [https://access.redhat.com/security/cve/cve-2021-44228](https://access.redhat.com/security/cve/cve-2021-44228)
- [https://access.redhat.com/security/cve/CVE-2021-4104](https://access.redhat.com/security/cve/CVE-2021-4104)
- [https://www.rapid7.com/blog/post/2021/12/10/widespread-exploitation-of-critical-remote-code-execution-in-apache-log4j/](https://www.rapid7.com/blog/post/2021/12/10/widespread-exploitation-of-critical-remote-code-execution-in-apache-log4j/)
- [https://blog.sonatype.com/a-new-0-day-log4j-vulnerability-discovered-in-the-wild](https://blog.sonatype.com/a-new-0-day-log4j-vulnerability-discovered-in-the-wild)
- [https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b](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](https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476) - Elasticsearch announcement
- [https://issues.apache.org/jira/browse/ZOOKEEPER-4423](https://issues.apache.org/jira/browse/ZOOKEEPER-4423) - Zookeeper’s discussion