A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1.
This announcement summarizes any potential impacts to Elastic products and related announcements for mitigations of the issue.
Elastic engineering and security teams continue to actively work on the analysis and any actions our users should perform, alongside identifying detection signatures that may be used to identify potential exploitation of the vulnerability.
All updates will be announced in this Security Announcements forum. These announcements may be tracked via and RSS feed.
Elasticsearch
Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager, however we are making a fix available for an information leakage attack also associated with this vulnerability. Additional details below.
Elastic Cloud
Our security testing has not identified any exploitable RCEs against any Elastic Cloud products. Our investigation continues and we will provide updates of any new findings.
As a normal practice we will update components with the latest version of Log4j as they become available.
APM Java Agent
APM Java Agent is only known to be exploitable when the Agent is configured with log_level=trace and at the same time using a PLAIN_TEXT log format. Additional details below.
Elastic Cloud Enterprise
Our security testing has not identified any exploitable vulnerabilities related to this issue. We are continuing to analyse the issue and will advise with any updates. As a normal practice we will update any components which include the vulnerable Log4j versions in the next release.
Elastic Cloud on Kubernetes
Our security testing has not identified any exploitable vulnerabilities related to this issue. We are continuing to analyse the issue and will advise with any updates. As a normal practice we will update any components which include the vulnerable Log4j versions in the next release.
Logstash
Logstash has no known viable attack vectors for remote code execution on JDKs newer than 8u191 and 11.0.1, but it is susceptible to DoS attacks. Additional details below.
Swiftype
Our security testing has not identified any exploitable RCEs against Swiftype products. Our investigation continues and we will provide updates of any new findings. We already have mitigations in place as a precaution and will update components with the latest version of Log4j as they become available.
Not Impacted
We have validated that the vulnerability does not exist in the following Elastic products:
APM Server
Beats
Cmd
Elastic Endgame
Elastic Maps Service
Endpoint Security
Enterprise Search
Kibana
Machine Learning
APM Java Agent Code Execution issue (ESA-2021-31)
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The APM Java Agent is impacted. The latest version of the APM Java Agent fixes this vulnerability. In versions 1.17.0-1.28.0, the only known way the Log4j vulnerability may be exploited is when the APM Java Agent is configured with log_level=trace and at the same time using a PLAIN_TEXT log format (log_format_stdout/log_format_file=PLAIN_TEXT).
Affected Versions:
Versions 1.17.0-1.28.0
Solutions and Mitigations:
Customers running versions prior to 1.28.1 should upgrade to the latest version.
In versions 1.17.0-1.28.0, the issue can be mitigated manually by setting system property -Dlog4j2.formatMsgNoLookups=true.
Elasticsearch announcement (ESA-2021-31)
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. Log4j is a standard logging library used by countless Java applications including Elasticsearch. Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager, however soon we will make available Elasticsearch 6.8.21 and 7.16.1 which will remove the vulnerable Log4j component and set the JVM option identified below.
Affected Versions:
Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j, as well as the Security Manager which mitigates the attack.
Solutions and Mitigations:
Users may upgrade to Elasticsearch 6.8.22 or 7.16.1 once they are releasedSet the JVM option -Dlog4j2.formatMsgNoLookups=trueLogstash announcement (ESA-2021-31)
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. Logstash uses Log4j as its logging subsystem and may be vulnerable.
When running on older JDKs, an attacker is able to inject and execute a remote Java class. On recent JDKs the attack is limited to potential DoS - causing data ingestion to temporarily stop - and information leakage, but no remote code execution attack vectors are known.
Affected Versions:
Logstash versions 6.8.x and 7.x up to 7.15.2, when configured to run on JDKs below 8u191 and 11.0.1, allow for remote loading of Java classes.
Docker images are susceptible to DoS but there is no known path for remote code execution.
Solutions and Mitigations:
The widespread flag -Dlog4j2.formatMsgNoLookups=true does NOT mitigate the vulnerability in Logstash, as Logstash uses Log4j in a way where the flag has no effect. It is therefore necessary to remove the JndiLookup class from the log4j2 core jar, with the following command:zip -q -d <LOGSTASH_HOME>/logstash-core/lib/jars/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLoo
3 个回复
God_lockin
赞同来自:
elastic 的博客中有提到es 里的security manager能有效的阻挡这个攻击，只是看你们对安全的重视程度和对es安全能力的信任程度了
laoyang360 - 《一本书讲透Elasticsearch》作者，Elastic认证工程师 [死磕Elasitcsearch]知识星球地址：http://t.cn/RmwM3N9；微信公众号：铭毅天下; 博客：https://elastic.blog.csdn.net
赞同来自:
laoyang360 - 《一本书讲透Elasticsearch》作者，Elastic认证工程师 [死磕Elasitcsearch]知识星球地址：http://t.cn/RmwM3N9；微信公众号：铭毅天下; 博客：https://elastic.blog.csdn.net
赞同来自:
铭毅一句话概括：
Kibana、Beats 不受任何影响。
Elasticsearch、Logstash 受到漏洞影响，需要紧急修复（尤其外网对外提供服务的集群）。
官方解读核心如下：
1、Log4j “核弹”级漏洞起因
2021 年 12 月 9 日，Log4j 的 GitHub 公开披露了一个影响 Apache Log4j 2 实用程序多个版本的高严重性漏洞 (CVE-2021-44228)。该漏洞影响了 Apache Log4j 2 的 2.0 到 2.14.1 版本。
Github地址：https://logging.apache.org/log4j/2.x/
本公告总结了对 Elastic 产品的任何潜在影响以及缓解问题的相关公告。
Elastic 官方工程和安全团队继续积极开展分析和（探讨）我们的用户应执行的任何操作，同时识别可用于识别漏洞潜在利用的检测签名。
所有更新都将在此安全公告论坛中公布。这些公告可以通过 和 RSS 提要进行跟踪。
发布订阅地址：
https://discuss.elastic.co/c/a ... 1.rss
如下中文翻译只解读了用户最关心的：Elasticsearch、Kibana、Logstash、Beats等产品线，对于 Elastic Cloud、APM 等读者们直接关注下文英文即可。
2、Elasticsearch 哪些产品线未受到影响？
Kibana
Beats
Cmd
APM Server
Elastic Endgame
Elastic Maps Service
Endpoint Security
Enterprise Search
Machine Learnin
3、Elasticsearch 哪些产品线受到影响？
Elasticsearch
Logstash
Elastic Cloud
APM Java Agent
Elastic Cloud Enterprise
Elastic Cloud on Kubernetes
Swiftype
4、Elasticsearch 如何修复漏洞？
4.1 Elasticsearch 公告 (ESA-2021-31)
Log4j 是包括 Elasticsearch 在内的无数 Java 应用程序使用的标准日志记录库。
由于我们使用了 Java 安全管理器，Elasticsearch 不易受此漏洞的远程代码执行影响，但是很快我们将提供 Elasticsearch 6.8.21 和 7.16.1，这将删除易受攻击的 Log4j 组件并设置下面标识的 JVM 选项。
4.2 Elasticsearch 受影响的版本
Elasticsearch 5.0.0+ 版本包含一个易受攻击的 Log4j 版本，以及缓解攻击的安全管理器（Security Manager）。
4.3 Elasticsearch 解决方案和缓解措施
方案一：用户可在 Elasticsearch 6.8.22 或 7.16.1 发布后升级。
方案二：设置 JVM 选项-Dlog4j2.formatMsgNoLookups=truePS: Elasticsearch 7.13.0 Log4j 版本如下：
[图片]
5、Logstash 如何修复漏洞？
5.1 Logstash 公告 (ESA-2021-31)
Logstash 使用 Log4j 作为其日志子系统，因此可能存在漏洞。
在旧版 JDK 上运行时，攻击者能够注入并执行远程 Java 类。
在最近的 JDK 上，攻击仅限于潜在的 DoS（导致数据摄取暂时停止）和信息泄漏，但没有已知的远程代码执行攻击载体。
5.2 Logstash 受影响的版本
Logstash 版本 6.8.x 和 7.x 到 7.15.2，当配置为在低于 8u191 和 11.0.1 的 JDK 上运行时，允许远程加载 Java 类。
Docker 镜像容易受到 DoS 的影响，但没有用于远程代码执行的已知路径。
5.3 Logstash 解决方案和缓解措施
广泛使用的标志 -Dlog4j2.formatMsgNoLookups=true 并不能缓解 Logstash 中的漏洞，因为 Logstash 以标志无效的方式使用 Log4j。
因此有必要使用以下命令从 log4j2 核心 jar 中删除 JndiLookup 类：zip -q -d <LOGSTASH_HOME>/logstash-core/lib/jars/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLooPS: logstash 7.13.0 对应的 log4j 版本：
[图片]
如果中文解读有误，以官方通报为准，为了保证信息的无损一致性，保留了原文全部内容。
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1.
This announcement summarizes any potential impacts to Elastic products and related announcements for mitigations of the issue.
Elastic engineering and security teams continue to actively work on the analysis and any actions our users should perform, alongside identifying detection signatures that may be used to identify potential exploitation of the vulnerability.
All updates will be announced in this Security Announcements forum. These announcements may be tracked via and RSS feed.
Elasticsearch
Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager, however we are making a fix available for an information leakage attack also associated with this vulnerability. Additional details below.
Elastic Cloud
Our security testing has not identified any exploitable RCEs against any Elastic Cloud products. Our investigation continues and we will provide updates of any new findings.
As a normal practice we will update components with the latest version of Log4j as they become available.
APM Java Agent
APM Java Agent is only known to be exploitable when the Agent is configured with log_level=trace and at the same time using a PLAIN_TEXT log format. Additional details below.
Elastic Cloud Enterprise
Our security testing has not identified any exploitable vulnerabilities related to this issue. We are continuing to analyse the issue and will advise with any updates. As a normal practice we will update any components which include the vulnerable Log4j versions in the next release.
Elastic Cloud on Kubernetes
Our security testing has not identified any exploitable vulnerabilities related to this issue. We are continuing to analyse the issue and will advise with any updates. As a normal practice we will update any components which include the vulnerable Log4j versions in the next release.
Logstash
Logstash has no known viable attack vectors for remote code execution on JDKs newer than 8u191 and 11.0.1, but it is susceptible to DoS attacks. Additional details below.
Swiftype
Our security testing has not identified any exploitable RCEs against Swiftype products. Our investigation continues and we will provide updates of any new findings. We already have mitigations in place as a precaution and will update components with the latest version of Log4j as they become available.
Not Impacted
We have validated that the vulnerability does not exist in the following Elastic products:
APM Server
Beats
Cmd
Elastic Endgame
Elastic Maps Service
Endpoint Security
Enterprise Search
Kibana
Machine Learning
APM Java Agent Code Execution issue (ESA-2021-31)
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The APM Java Agent is impacted. The latest version of the APM Java Agent fixes this vulnerability. In versions 1.17.0-1.28.0, the only known way the Log4j vulnerability may be exploited is when the APM Java Agent is configured with log_level=trace and at the same time using a PLAIN_TEXT log format (log_format_stdout/log_format_file=PLAIN_TEXT).
Affected Versions:
Versions 1.17.0-1.28.0
Solutions and Mitigations:
Customers running versions prior to 1.28.1 should upgrade to the latest version.
In versions 1.17.0-1.28.0, the issue can be mitigated manually by setting system property -Dlog4j2.formatMsgNoLookups=true.
Elasticsearch announcement (ESA-2021-31)
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. Log4j is a standard logging library used by countless Java applications including Elasticsearch. Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager, however soon we will make available Elasticsearch 6.8.21 and 7.16.1 which will remove the vulnerable Log4j component and set the JVM option identified below.
Affected Versions:
Elasticsearch versions 5.0.0+ contain a vulnerable version of Log4j, as well as the Security Manager which mitigates the attack.
Solutions and Mitigations:
Users may upgrade to Elasticsearch 6.8.22 or 7.16.1 once they are releasedSet the JVM option -Dlog4j2.formatMsgNoLookups=trueLogstash announcement (ESA-2021-31)
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. Logstash uses Log4j as its logging subsystem and may be vulnerable.
When running on older JDKs, an attacker is able to inject and execute a remote Java class. On recent JDKs the attack is limited to potential DoS - causing data ingestion to temporarily stop - and information leakage, but no remote code execution attack vectors are known.
Affected Versions:
Logstash versions 6.8.x and 7.x up to 7.15.2, when configured to run on JDKs below 8u191 and 11.0.1, allow for remote loading of Java classes.
Docker images are susceptible to DoS but there is no known path for remote code execution.
Solutions and Mitigations:
The widespread flag -Dlog4j2.formatMsgNoLookups=true does NOT mitigate the vulnerability in Logstash, as Logstash uses Log4j in a way where the flag has no effect. It is therefore necessary to remove the JndiLookup class from the log4j2 core jar, with the following command:zip -q -d <LOGSTASH_HOME>/logstash-core/lib/jars/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLoo