我读了很多关于这个问题有多严重的文章，并了解在我们公司正在生产和更新使用易受攻击版本的服务器的代码中找到它的选项。
我找不到的是，如果某个特定的服务器没有安装Java，也就是说，如果我以root身份登录并运行java -version并获得java: command not found，这个服务器是否完全安全，不会出现这个问题，这样我就可以继续前进了？
我最初的直觉是：没有Java——没有问题。然而，GitHub发布了企业服务器的更新，声明：
CRITICAL：Log4j库中的一个远程代码执行漏洞，被识别为CVE-2021-44228，影响了3.3.1之前的所有版本的GitHub Enterprise Server。Log4j库用于GitHub Enterprise Server实例上运行的开源服务。此漏洞已在GitHub Enterprise Server 3.0.22、3.1.14、3.2.6和3.3.1版本中修复。有关更多信息，请参阅GitHub博客上的这篇文章。
然而Java并没有安装在他们的企业服务器上。
我猜有问题的服务一定是在docker容器中运行的Java。因此，我认为我需要考虑机器上的Java或容器中运行的Java。
有没有其他我没有考虑过的隐藏方式可以运行这个log4j进程？
log4j2是一个库，必须由正在运行的java进程使用，才能被修复。但您是对的，检查java命令是否安装到命令行是不够的。
这里有两个选项(并不意味着完整(，说明如果没有命令行上的java命令，您的系统可能仍然存在漏洞。
- Java可以下载到一个目录中，而无需将Java命令或目录添加到可执行的PATH中。通过使用.bash(或.bat(脚本，仍然可以启动指向下载的java版本的java进程。但是，当目录没有添加到路径中时，您将不会发现java命令已启用
- Java可能在docker容器中运行。java命令只能在docker容器内部使用，但从外部看不到。我不确定是否需要额外的漏洞来突破的容器，如果这很容易做到，而不需要额外的努力
我还没有完整的答案，但非常肯定地NO即使没有安装Java，没有安装Docker，Java没有在进程列表中运行，Java也不在您的yum/apt安装的应用程序列表中，您也不安全。
我没有考虑过的一个明显的案例是将Java作为JRE添加到应用程序中。
我们拥有的Coverity平台服务器没有安装Java，但Java正在运行，例如ps -ax | grep java
/home/coverity/cov_platform-2021.9.0/jre/bin/java -Djava.awt.headless=true -Djdk.tls......
要弄清楚JRE中是否包含一个易受攻击的Log4j版本要困难得多。
此外，仅仅检查进程列表也是不够的。在这种情况下，进程列表包含java，但Java只能在被另一个进程触发时运行，例如cron、nginx等