Elasticsearch7 Update

Created:
Author: Christoph Stoettner
Read in about 3 min · 482 words

Things to do

Photo by AbsolutVision | Unsplash

CVE-2021-44228 was a very serious problem end of 2021, and we are still finding new occurrences, or security teams scan servers and find vulnerable log4j files. Don’t get me wrong most of these occurrences are not vulnerable any more, because the JVM is hardened like in the Elasticsearch 7 containers, or they use of the JVM parameter -Dlog4j2.formatMsgNoLookups=true.

A good summary and explanation can be found in Mitigate Log4j / Log4Shell in Elasticsearch (CVE-2021-44228) and Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 . So some versions of Elasticsearch 7 are using the vulnerable library, but are not vulnerable and provide the RCE, because the official Elasticsearch images are using the Java Security Manager and the images from HCL are on Java 11 which is not vulnerable for RCE and information leakage with Log4Shell.

bash-5.0# java -version
openjdk version "11.0.9" 2020-10-20
OpenJDK Runtime Environment (build 11.0.9+11-alpine-r0)
OpenJDK 64-Bit Server VM (build 11.0.9+11-alpine-r0, mixed mode)

Elasticsearch mitigation summary matrix

So the Security Bulletin: Apache Log4j 2 Vulnerability in Elasticsearch distributed in HCL Connections Component Pack(CVE-2021-44228) is not wrong when it tells us, that Connections 7 is not vulnerable for the log4shell CVE, but Componentpack 7.0.0.2 is using Elasticsearch 7.10.1 and this is distributed with log4j < 2.17.0.

I tried to find an update in the knowledge base, but couldn’t find more as the mentioned security bulletin. So I opened a case and first I got told that the image is not vulnerable, and no updates are available, but I asked for updated images because the security team at my customer does not accept this.

Yesterday I got the following answer:

ES7 was not affected, however, out of an abundance of caution they did merge log4j 2.17.0 into their ES7 image so we have done the same. The existing log4j on our ES7 docker image has been deleted and replaced with 2.17.0.

The latest ES7 image which includes the updated log4j 2.17.0 is available on Flexnet. Below is the link to Connections 7 downloads: https://hclsoftware.flexnetoperations.com/flexnet/operationsportal/entitledDownloadFile.action?downloadPkgId=HCL_Connections_7.0&orgId=HCL

The customer should download the following:

  1. ReadMe which includes instructions to load and register the new ES7 docker image along w/ the image and helm chart: ReadMe for the Elastic Search 7 update for HCL Connection Component Pack 3.28KB May 20, 2022 elasticsearch720220310-143242-ReadMe.txt

  2. This package contains an update for Elastic Search 7 for HCL Connections Component Pack v7.0.0.x and v7.0.0.2 560.03MB May 02, 2022 elasticsearch720220310-143242.tgz

  3. This package contains an updated helm chart for Elastic Search 7 for HCL Connections Component Pack v7.0.0.x and v7.0.0.2 38.6KB May 02, 2022 elasticsearch7-0.1.0-20220310-143242.tgz

HCL Support

The images to update Elasticsearch 7 are availble since May on Flexnet!

As this is nowhere documented, I asked for an updated knowledge base article and post it here, so you can update your environment too. Main advantage of the image update: no more questions why your software is staying with old and vulnerable libraries.

Author
Add a comment
Error
There was an error sending your comment, please try again.
Thank you!
Your comment has been submitted and will be published once it has been approved.

Your email address will not be published. Required fields are marked with *

Suggested Reading
Aaron Burden: Fountain pen and a notebook

Today I activated Elasticsearch Metrics and Typeahead Search on my demo HCL Connections cluster .

To my surprise the indices weren’t created and I got errors on the wsadmin.sh commands.

SearchService.createESQuickResultsIndex()

I checked the Elasticsearch pods which showed a running state, but the logs showed following messages:

Created:
Last Update:
Read in about 3 min
Card image cap

Elasticsearch in HCL Connections Componentpack is secured with Searchguard and needs certificates to work properly. These certificates are generated by bootstrap during the initial container deployment with helm.

These certificates are valid for 10 years (chain_ca.pem) or 2 years (elasticsearch*.pem) and stored in the Kubernetes secrets elasticsearch-secret, elasticsearch-7-secret. So when your HCL Connections deployment is running for 2 years, the certficates stop working.

Created: Read in about 3 min
Card image cap

Last week I played around with the HCL Connections documentation to backup Elasticsearch in the article Backup Elasticsearch Indices in Component Pack .

In the end I found that I couldn’t get the snapshot restored and that I have to run a command outside of my Kubernetes cluster to get a snapshot on a daily basis. That’s not what I want.

Created: Read in about 4 min