Today, we have released the security and bug fix release of Elasticsearch 1.4.3, based on Lucene 4.10.3, and Elasticsearch 1.3.8. You can download them and read the full changes list here:
THESE RELEASES FIX A VULNERABILITY IN SCRIPTING. WE ADVISE ALL USERS TO UPGRADE.
For blog posts about past releases see:
Elasticsearch versions 1.3.0-1.3.7 and 1.4.0-1.4.2 have a vulnerability in the Groovy scripting engine. The vulnerability allows an attacker to construct Groovy scripts that escape the sandbox and execute shell commands as the user running the Elasticsearch Java VM.
We have been assigned CVE-2015-1427 for this issue.
Versions 1.3.8 and 1.4.3 disable sandboxing for Groovy by default. As a consequence, dynamic script execution is disabled for Groovy.
If you are running a vulnerable version, you should either upgrade to v1.3.8 or v1.4.3, or disable dynamic Groovy scripts by adding this setting to all nodes in the cluster:
This will turn off the Groovy sandbox, thus preventing dynamic Groovy scripts from being accepted inline as part of a request or from being retrieved from the special
In the meantime, you can still use Groovy scripts by saving them as files in the
config/scripts directory on every data node. See Running scripts without dynamic scripting for more information about how to do this.
The loss of Groovy as a safe dynamic scripting language is a blow to Elasticsearch. We use scripts in the update API, in the search API, and as part of the aggregations framework. They allow our users to perform custom tricks that are not easily expressed through a static API.
Unfortunately, after discussing the issue with the Groovy team, we have come to the conclusion that the Groovy language is too dynamic to be properly contained by a sandbox. This leaves us with the Lucene Expressions language as the only dynamic scripting language available by default. While Expressions are fast, they are currently very limited: they operate only on numeric fields and don't support loops.
We will be investigating extending Expressions to become a more powerful (but safe!) mini-language, that will support at least the most common use cases that our script users have today. This is a long term project, and will take time to evolve.