Kibana Local File Inclusion Flaw CVE-2018-17246

By
Elastic Engineering

In the past few days, a number of tweets and news stories have emerged about CVE-2018-17246, a bug in Kibana that could result in including any arbitrary file from the filesystem. This issue was fixed over a month ago in 6.4.3 and 5.6.13, and while we generally don’t publish additional information describing security bugs that have already been fixed, there has been some confusion surrounding this one, so we want to make sure accurate information about the problem is out there.

The Bug

The bug in question is known as a Local File Inclusion bug, or LFI. The short explanation is a remote attacker can make Kibana load and run a file from the local disk. In the case of the Kibana bug, it will try to load the content of the file it loads as JavaScript code. In the examples we’re seeing, the file /etc/passwd is being included. Note that this proof of concept simply crashes Kibana since the contents of /etc/passwd are not JavaScript code.

In any running system, including libraries from external files is a very normal operation. What’s not normal is when an attacker is able to trick a running system into loading a file of their choosing from the disk. A bug like this could be quite dangerous if an attacker is able to first upload a file somewhere on disk, then tell Kibana to load and run it. This is an example of why the practice of segmenting services is generally a good idea.

The Impact

Customers running the Elasticsearch Service on Elastic Cloud can be assured that their clusters are already updated to fix this vulnerability. If you are running on another Elasticsearch service (such as Amazon ES) or are managing your own Elasticsearch deployment, you'll need to make sure you take one of the steps listed below to update or workaround this issue.

The Exploit

A Cyberark advisory contained an example exploit — the same exploit making its way around Twitter. Using this simple exploit code, anyone can request a Kibana URL and essentially crash Kibana. What this example can’t do, though, is view contents of arbitrary files. While the demo shown uses /etc/passwd, the contents of the file don’t end up sent to the user. Some details are logged to the Kibana log file as part of the crash report, but just the first few lines.

Our Response

The Cyberark advisory contains a timeline at the bottom. They alerted Elastic to the issue on Oct. 23, we analyzed it, and promptly fixed it with a new release of the Elastic Stack on Nov 6. We then updated all Elastic Cloud systems immediately.

We assigned this ESA-2018-18, which is one of our Elastic Security Advisory IDs, as well as CVE-2018-17246. If you’re using Kibana versions 6.4.3 or 5.6.13 (or later), you have nothing to worry about.

The best way to deal with this issue is to apply timely security updates. But if you can’t apply updates right away, we also have a workaround available. You can disable the Kibana Console plugin which prevents the codepath in question from being executed. The Console plugin can be disabled by setting console.enabled: false in the kibana.yml file.

It Takes a Village

If you ever find yourself with interesting information about a potential security flaw affecting the Elastic Stack, such as Kibana in this instance, feel free to let us know about it. Elastic closely watches the security@elastic.co address, we take reports seriously, reply promptly, and do our best to fix the problem as fast as possible.

Finally, if you’re not comfortable taking these and other security measures yourself, please consider using our Elasticsearch Service on Elastic Cloud, where security is always enabled.