Updated: December 13, 2021 (click for details):

• Updated the fixed version of Elasticsearch 6.8 from 6.8.22 to 6.8.21 as per the updated Elastic Security Alert
• Added information about when 6.8.21 and 7.16.1 are expected to be released (December 13th).
• Added reference to a related article which provides further information on the Elastic software implications for Liferay Enterprise Search (LES) subscribers.
• Added statement on the Elasticsearch 6/7 connector implications.

Updated: December 15, 2021 (click for details):

• Elasticsearch 7.16.x has been added to Liferay's Search Engine Compatibility Matrix (DXP 7.1-7.4).

Updated: December 16, 2021 (click for details):

• Updated the vulnerability information based on the recent edits made by Elastic to their Security Alert.

Updated: December 19, 2021 (click for details):

• Added information regarding CVE-2021-45105. Elasticsearch has no known vulnerabilities to CVE-2021-45105, though Elastic is preparing to release 7.16.2 and 6.8.22 to include the latest version of log4j (2.17.0) on Dec 19th. (via Elastic Security Alert)

Updated: December 20, 2021 (click for details):

• Elastiscsearch 7.16.2 and 6.8.22 are now available. These releases include the most recent version of Log4j (2.17.0).

Updated: April 5, 2022 (click for details):

• The Sidecar Elasticsearch version has been upgraded to 7.17.0 in DXP 7.4 Update 17. Please refer https://issues.liferay.com/browse/LPS-145631 to for more details.

The following issues may affect the functionality of your Liferay DXP, Liferay Enterprise Search environment and your Elastic Stack.

Deployments which might be impacted

• Elasticsearch versions prior to 6.8.22 and 7.16.2

Vulnerability Information

Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Elasticsearch running on JDK8 or below is susceptible to an information leak via DNS which is fixable by the JVM option identified below. This option is effective for Elasticsearch versions 5.6.11+, 6.4+, and 7.0+.

As of December 13, 2021, we have released Elasticsearch 6.8.21 and 7.16.1 which set the JVM option identified below and remove the vulnerable JndiLookup class from Log4j out of an abundance of caution. If you are on a 6.x version prior to 6.4.0 and upgrading is not possible, you can follow the instructions here 184.

Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. For versions 5.6.11 - 5.6.16, this can be mitigated by setting the JVM option. Users on an earlier version of 5.x, are recommended to upgrade to 5.6.16. If you are on a 5.x version prior to 5.6.11 and upgrading is not possible, you can follow the instructions here . Please note that while we provide these remediations, Elasticsearch 5 is not a supported version, and we always recommend updating to the latest release.

Elasticsearch 2 and earlier used a Log4j version that is not vulnerable to the newly discovered flaw. Please note that Elasticsearch 2 is not a supported version, and we always recommend updating to the latest release.

For users running on Elastic Cloud, versions 7.2+ have never been susceptible to either the RCE or the information leakage as these versions already run on JDK11 or higher. We recommend users running any version of Elasticsearch earlier than 7.2 restart their clusters as soon as possible - the JVM option identified below will automatically be applied and fully protect clusters on restart. Any new clusters will be deployed with the JVM option included. See Elastic Cloud announcement for more details[Update - April 5, 2022] The Sidecar Elasticsearch version has been updated to 7.17.0 in DXP 7.4 Update 17. Please refer https://issues.liferay.com/browse/LPS-145631 to for more details.

Affected Versions:

Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j. Elasticsearch 5 is susceptible to both remote code execution and an information leak via DNS. We’ve confirmed that the Security Manager mitigates the remote code execution attack in Elasticsearch 6 and 7.

Solutions and Mitigations:

The simplest remediation is to set the JVM option  -Dlog4j2.formatMsgNoLookups=true and restart each node of the cluster.
For Elasticsearch 5.6.11+, 6.4+, and 7.0+, this provides full protection against the RCE and information leak attacks.

Users may upgrade to Elasticsearch 7.16.1 or 6.8.21 , which were released on December 13, 2021. These releases do not upgrade the Log4j package, but mitigate the vulnerability by setting the JVM option -Dlog4j2.formatMsgNoLookups=true and remove the vulnerable JndiLookup class from the Log4j package.

Note: In both of these scenarios, some vulnerability scanners may continue to flag Elasticsearch in association with this vulnerability based on the Log4j version alone. However, any of the above mitigations sufficiently protect both remote code execution and information leakage.

[Update Dec 14th] Log4j 2.16.0 has been released to address CVE-2021-45046. This does not change the mitigation guidance for Elasticsearch described above, that does not require an update to Log4j 2.16.0. Elastic guidance remains to either apply the JVM option described above and restart all nodes, or upgrade Elasticsearch to 7.16.1 or 6.8.21.

If Elasticsearch is managed by ECK, set the JVM option in the Elasticsearch custom resource podTemplate specification.

If Elasticsearch is managed by ECE, for versions 6.x and <7.2, we recommend reinstalling stackpacks, which have been patched to include the JVM option mitigation. After re-installing relevant stackpacks, we recommend restarting deployments. For the 5.x series, we recommend overriding the JVM options to add the property that will mitigate the vulnerability, and restart the cluster to pick up the change: For details and guidance, please reach out to Elastic support.

Details on Elasticsearch information leakage

The information leakage vulnerability in Log4j enables an attacker to exfiltrate certain environmental data via DNS - it does not permit access to data within the Elasticsearch cluster. The data that can be leaked is limited to those available via Log4j “lookups”, which includes system environment variables and a limited set of environmental data from other sources. For a complete list, see the Log4j Lookups documentation .

Notes of PoCs expanding RCEs to recent Java versions

We are actively monitoring developments in the security community, such as this one 74, which seek to expand the JDKs and scenarios where this exploit will apply. Our implementation of the Java Security Manager in Elasticsearch 6 and 7, in combination with JDK9 or greater, continues to protect against all known PoC’s. While these efforts seek to provide a viable RCE even when com.sun.jndi.ldap.object.trustURLCodebase=false (as in recent JDKs), our Security Manager cuts off the attack earlier in the process, preventing both remote and local (on the class path) variants of the attack.

[Update Dec 18th] Elasticsearch has no known vulnerabilities to CVE-2021-45105. We are preparing 7.16.2 and 6.8.22 which will include the latest version of Log4j (2.17.0).

Search Engine Compatibility Matrix

Reference the information here for the detailed Elasticsearch compatibility including the compatible connector versions and required patch levels.

Updated (Dec 15, 2021): Elasticsearch 7.16.x has been added to the compatibility matrix.

Vendor References

https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476

---

Elastic, Elasticsearch, and X-Pack are trademarks of Elasticsearch BV, registered in the U.S. and in other countries.