简体   繁体   English

如果未安装 Java,您是否可以免受 log4j CVE-2021-44228 的影响?

[英]Are you safe from log4j CVE-2021-44228 if Java is not installed?

I have read a lot about how bad this issue is and understand the options available to locate it within the code our company is producing and update servers that are using vulnerable versions.我已经阅读了很多关于这个问题有多严重的信息,并且了解了在我们公司正在生产和更新使用易受攻击版本的服务器的代码中找到它的可用选项。

What I am unable to find is if a particular server does not have Java installed ie if I log in as root and run java -version and get java: command not found is this server completely safe from this issue and so I can move on?我无法找到的是,如果特定服务器没有安装 Java,即如果我以 root 身份登录并运行java -version并获得 java -version 并获取java: command not found ,那么我可以从这个问题完全安全地移动这个服务器吗?

My initial instinct was: no Java - no issue.我最初的直觉是:没有 Java - 没问题。 However, GitHub released an update for their Enterprise servers stating:但是,GitHub 发布了针对其企业服务器的更新,说明:

CRITICAL: A remote code execution vulnerability in the Log4j library, identified as CVE-2021-44228, affected all versions of GitHub Enterprise Server prior to 3.3.1.严重:Log4j 库中的远程代码执行漏洞,标识为 CVE-2021-44228,影响 GitHub Enterprise Server 3.3.1 之前的所有版本。 The Log4j library is used in an open-source service running on the GitHub Enterprise Server instance. Log4j 库用于在 GitHub Enterprise Server 实例上运行的开源服务中。 This vulnerability was fixed in GitHub Enterprise Server versions 3.0.22, 3.1.14, 3.2.6, and 3.3.1.此漏洞已在 GitHub Enterprise Server 版本 3.0.22、3.1.14、3.2.6 和 3.3.1 中修复。 For more information, please see this post on the GitHub Blog.有关更多信息,请参阅 GitHub 博客上的这篇文章。

And yet Java is not installed on their enterprise server.然而 Java 并未安装在他们的企业服务器上。

I am guessing the offending service must be with Java running in a docker container.有问题的服务必须是在 docker 容器中运行的 Java 。 So I think I need to consider Java on the machine or Java running in a container.所以我想我需要考虑机器上的 Java 或容器中运行的 Java。

Are there other hidden ways I have not considered in which this log4j process can be running?还有其他我没有考虑过的隐藏方式可以运行这个 log4j 进程吗?

log4j2 is a library that must be used by a running java process, to be vulnarable. log4j2 是一个运行中的 java 进程必须使用的库,它是易受攻击的。 But you are right, that checking if the java command is installed to the command line is not enough.但你是对的,检查java命令是否安装到命令行是不够的。

Here are two options (not meant to be complete), how your system could still be vulnerable without having the java command available on the command line.这里有两个选项(并不完整),如果没有命令行上可用的java命令,您的系统如何仍然容易受到攻击。

  • Java could be downloaded into a directory without adding the java command or directory to the executable PATH. Java 可以下载到目录中,而无需将 java 命令或目录添加到可执行路径中。 By using a.bash (or.bat) script a java process pointing to the downloaded java version could still be started.通过使用 a.bash (or.bat) 脚本,仍然可以启动指向下载的 java 版本的 java 进程。 But when the directory is not added to the path, you will not find the java command enabled.但是当目录没有添加到路径时,你会发现没有启用java命令。
  • Java could be running inside of a docker container. Java 可以在 docker 容器内运行。 the java command would only be available inside of your docker container but not visible from outside. java 命令仅在您的 docker 容器内部可用,但从外部看不到。 I am not sure if an additional exploit would be required to break out of the container of if this is easily possible without extra effort.我不确定是否需要额外的利用来突破容器,如果这很容易而不需要额外的努力。

I don't have a full answer yet but very definitely NO you are not safe even if Java is not installed, and Docker is not installed, and Java is not running in the process list, and Java is not in your yum/apt installed applications lists. I don't have a full answer yet but very definitely NO you are not safe even if Java is not installed, and Docker is not installed, and Java is not running in the process list, and Java is not in your yum/apt installed应用程序列表。

An obvious case I had not considered is when Java is added to an app as a JRE.我没有考虑过的一个明显情况是 Java 作为 JRE 添加到应用程序中。

A Coverity platform server we have does not install Java but Java is running eg ps -ax | grep java我们拥有的 Coverity 平台服务器没有安装 Java 但 Java 正在运行,例如ps -ax | grep java ps -ax | grep java

/home/coverity/cov_platform-2021.9.0/jre/bin/java -Djava.awt.headless=true -Djdk.tls......

Working out if a vulnerable version of Log4j is included in that JRE is much harder.确定 JRE 中是否包含易受攻击的 Log4j 版本要困难得多。

Further, just checking the process list is not enough either.此外,仅检查进程列表也是不够的。 In this case the process list contained java but Java may only be run when triggered by another process eg cron , nginx , etc在这种情况下,进程列表包含java但 Java 只能在由另一个进程触发时运行,例如cronnginx

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 CVE-2021-44228 和 log4j 1.2.17 - CVE-2021-44228 and log4j 1.2.17 log4j 漏洞 CVE-2019-17571 与 CVE-2021-44228 - log4j vulnerability CVE-2019-17571 vs CVE-2021-44228 log4javascript 是否容易受到 Apache Log4j(Java 日志库)远程代码执行 CVE-2021-44228 的攻击? - Is log4javascript vulnerable to Apache Log4j (Java logging library) remote code execution CVE-2021-44228? Log4JS npm package 是否容易受到 CVE-2021-44228 Log4J 漏洞的攻击 - Is Log4JS npm package vulnerable to CVE-2021-44228 Log4J vulnerability AWSGlueETL 依赖 log4j 安全漏洞`CVE-2021-44228` - AWSGlueETL is dependent log4j security vulnerabilities `CVE-2021-44228` log4j 漏洞 CVE-2021-44228 是否影响 logstash-logback-encoder - Does the log4j vunerability CVE-2021-44228 affect logstash-logback-encoder 是否存在受当前 log4j / CVE-2021-44228 安全问题影响的 r 软件包? - Are there r packages affected by the current log4j / CVE-2021-44228 security issue? 哪个版本的 Kafka 因 log4j CVE-2021-44228 而受到影响? - Which version of Kafka are impacted due to log4j CVE-2021-44228? Google Cloud Platform 和 PCF 上的 Log4j 漏洞 (CVE-2021-44228) - Log4j Vulnerability (CVE-2021-44228) on Google Cloud Platform and PCF 修复 Apache 风暴的 log4j 漏洞 (CVE-2021-44228)? - fix for log4j vulnerability (CVE-2021-44228) for Apache storm?
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM