这是关于CVE-2021-44228针对log4j-core jar报告的漏洞，已在Log4J v2.15.0中修复。
我们通过slf 4j使用Logback API。这可以通过下面的代码来确认。
final StaticLoggerBinder binder = StaticLoggerBinder.getSingleton();
System.out.println(binder.getLoggerFactory());
System.out.println(binder.getLoggerFactoryClassStr());
//output:
//ch.qos.logback.classic.LoggerContext[default]
//ch.qos.logback.classic.util.ContextSelectorStaticBindermvn dependency:tree显示类路径中的log4j-core API（版本〈2.15）（直接和可传递依赖）。
由于在类路径中维护log4j-core，该应用程序是否仍存在漏洞？谢谢！
1条答案
按热度按时间bqucvtff1#
要使漏洞对您构成风险，需要同时具备以下几点：
1.您的环境中存在相应的库
1.在运行时环境中确实会发生相应的库调用
1.第三方用户找到了一种方法来将他们的（未经检查的）输入传递到该库调用中
这里没有人能告诉您“2.”和“.3”是否适用于您的环境。
但是：当你删除了1.，你就知道“2.”和“3.”不再可能了。2或者反过来说，只要你100%确信没有一条路径可以让用户将数据输入到你的系统中，并使其进入相应的API，那么你甚至可以将库留在你的环境中。3但是正如前面所说的，* 拥有 * 这个库是这个链的第一个强制性元素。所以，当这个元素存在的时候，可能有人明天会写代码让你得到“2”和“3”！
因此，请记住高级管理层的观点：最有可能的是，“业务”决策可能是：将风险降低到0，因此请确保您的机器上甚至没有相应的JAR。
在我的bigcorp环境中，命令非常简单：* 不要浪费任何时间来分析您的代码是否使用了相应的接口。当您的项目包含有漏洞的JAR时，请立即升级它。句号。*