Vulnerability in High level client fixed in Elasticsearch 7.11.0, when in OpenSearch?

The following vulnerability was picked up by our SNYK, this is fixed in Elasticsearch 7.11.0, but since Amazon ES is now OpenSearch and still on 7.10.2 this is not fixed. When does OpenSearch expect to fix this?
The description of the vulnerability as extracted from the SNYK report:

  • Introduced through: org.elasticsearch.client:elasticsearch-rest-high-level-client@7.10.2
  • Fixed in: org.elasticsearch:elasticsearch@7.11.0

Overview
org.elasticsearch:elasticsearch is a Distributed, RESTful Search Engine.
Affected versions of this package are vulnerable to Information Exposure when Document or Field Level Security is used. GET requests do not properly apply security permissions when executing a query against a recently updated document. This affects documents that have been updated and not yet refreshed in the index. This could result in the search disclosing the existence of documents and fields the attacker should not be able to view.

This definitely requires additional research, but FYI, OpenSearch uses a different security engine than Elasticsearch so it’s questionable that this applies. I wouldn’t automatically assume that all ES bugs apply to OpenSearch.

Thank you. We are using Amazon ES, and the SNYK vulnerability was reported on our Amazon ES instance, so I am curious how SNYK picked up this vulnerability, surely then it indicates it does exist.

The problem is our company standard for security is the SNYK report, we are now considering moving over to Elastic Services since they are already on 7.14 where the issue is fixed, so if Amazon ES is still showing this issue from the SNYK report, then I do not know what is happening there, this is all very unclear and messy.

Totally get it messiness here. I flagged this issue with the engineering team yesterday.

To be clear, Amazon Elasticsearch Service uses the same security engine as OpenSearch (well, technically an earlier version) and the document and field level security are different than what is provided by Elasticsearch. My personal, uninvestigated guess is that it’s a false positive from synk.

Thank you, that is good to know. Yes agreed about Snyk, I have become suspicious about Snyk and have been researching this for the past couple of hours, hope I can come up with something concrete.

For the sake of supplying information, we are getting 3 similar vulnerabilities reported by Snyk, below I list them, the first is of Medium ranking, the other 2 low, I think we are more worried about the Medium one:
Vulnerability 1

  • Title: Information Disclosure
  • SNYK #: SNYK-JAVA-ORGELASTICSEARCH-1061930
  • Score (out of 10): 4.3 (Medium)
  • Description: Affected versions of this package are vulnerable to Information Disclosure. An information disclosure flaw exists in the async search API. Users who execute an async search will improperly store the HTTP headers. An Elasticsearch user with the ability to read the .tasks index could obtain sensitive request headers of other users in the cluster.
  • Introduced through: org.elasticsearch.client:elasticsearch-rest-high-level-client@7.10.2
  • Fixed in: org.elasticsearch:elasticsearch@7.11.2, @6.8.15

Vulnerability 2

  • Title: Information Disclosure
  • SNYK #: SNYK-JAVA-ORGELASTICSEARCH-
  • Score (out of 10): 2.6 (Low)
  • Description: Affected versions of this package are vulnerable to Information Disclosure. A document disclosure flaw was found in the Elasticsearch suggester and profile API when Document and Field Level Security are enabled. The suggester and profile API are normally disabled for an index when document level security is enabled on the index. Certain queries are able to enable the profiler and suggester which could lead to disclosing the existence of documents and fields the attacker should not be able to view.
  • Introduced through: org.elasticsearch.client:elasticsearch-rest-high-level-client@7.10.2
  • Fixed in: org.elasticsearch:elasticsearch@7.11.2, @6.8.15

Vulnerability 3

  • Title: Information Exposure
  • SNYK #: SNYK-JAVA-ORGELASTICSEARCH-
  • Score (out of 10): 2.6 (Low)
  • Description: Affected versions of this package are vulnerable to Information Exposure when Document or Field Level Security is used. GET requests do not properly apply security permissions when executing a query against a recently updated document. This affects documents that have been updated and not yet refreshed in the index. This could result in the search disclosing the existence of documents and fields the attacker should not be able to view.
  • Introduced through: org.elasticsearch.client:elasticsearch-rest-high-level-client@7.10.2
  • Fixed in: org.elasticsearch:elasticsearch@7.11.0

Again, this is just my high level review w/o testing, so grains of salt are needed.

Vulnerability 1: Open Distro and OpenSearch use a unique implementation of async search (see: Introducing Asynchronous Search in Open Distro for Elasticsearch | Open Distro). This is likely not affecting you.

Vulnerability 2 & 3: Both are related to document and field level security which are distinct in the Open Distro/OpenSearch security model

Vulnerability 1: this async search vulnerability is related to ELv2 Elastic licensed code; not OpenSearch. The async search API was licensed ALv2 but it was removed in PR#10, because the implementation is licensed ELv2.

Vulnerability 2: this Document and Field Level Security vulnerability is in licensed ELv2 code and was removed (along w/ HLRC) in OpenSearch in PR#16

Vulnerability 3: this Document and Field Level Security vulnerability is in licensed ELv2 code and was removed (along w/ HLRC) in OpenSearch in PR#16

1 Like

Thank you very much guys, this is of great help. I have to figure out now how the high-level client is upgraded, or why SNYK is still picking it up as Elasticsearch client 7.10.2. Snyk shall have to change their tests to include OpenSearch versions and differentiate, but how is the current OpenSearch High-level client versioned and how do we update to that version?

It’s a good call out on these vuln scanning tools - they’re likely to pick up a lot of hard-to-decipher noise until the two projects are distinct top-to-bottom.

I believe the OpenSearch clients will be versioned along side OpenSearch (starting with 1.0)