Apache Log4j 漏洞影响有多大？

Posted 2022-01-20 Java技术栈

点击关注公众号，Java干货及时送达

Apache Log4j2 漏洞最新进展及解决方案：Log4j 2.3.1 发布！又是什么鬼？？

---

文 | 局长
出品 | OSC开源社区（ID：oschina2013）

来自 Google Open Source Insights Team 的安全研究人员通过调查 Maven Central 中所有软件包的所有版本，以更好地了解最近曝出的 Log4j 漏洞对整个 JVM 语言生态系统的影响，同时还跟踪了正在进行的缓解受影响软件包的工作。

研究人员发现，截至 2021 年 12 月 16 日，来自 Maven Central 的 35,863 个可用软件包依赖于存在漏洞的 log4j 代码。这意味着 Maven Central 上超过 8% 的软件包至少有一个版本受漏洞影响（此数字不包括所有 Java 软件包，例如直接分发的二进制文件）

就生态系统影响而言，8% 是相当巨大的数字。因为对 Maven Central 生态的平均影响数值为 2%，中位数则低于 0.1%。

如记录漏洞的 CVE 所述，大多数受影响的软件包来自间接依赖项（即自身依赖项的依赖项），也就是说它们没有将 log4j 明确定义为依赖项，而是作为传递依赖项被引入进来。

这正是 JVM 生态整体上修复此漏洞异常困难的原因。安全研究人员称，在撰写文章时，只修复了近五千个受影响的软件包，还有 30000 多个软件包会受到漏洞的影响。

简单来说就是，漏洞在依赖关系链中嵌套得越深，修复漏洞所需的步骤就越多。下图显示了受影响的 log4j 包（核心或 api）首次出现在依赖图中的深度的直方图。

对于超过 80% 的软件包，该漏洞的深度超过一级，其中大多数受影响的级别下降了 5 个级别（有些甚至下降了 9 个级别）。这些包将需要在依赖树的所有部分进行修复，而且首先从最深处的依赖关系开始。

修复漏洞的另一个困难之处由解析算法 (resolution algorithm) 和需求规范约定中生态系统层级的选择引起。

在 Java 生态中，开发者通常的做法是指定软件版本方面的“软”要求——假设没有其它版本的相同包出现在依赖关系图中，解析算法会使用指定的明确版本。

对于此类修复，通常需要维护者采取更加明确的行动，以将依赖需求更新为修补后的版本。

这种做法与其它生态形成了鲜明的对比，例如在 npm 软件包中，开发者通常会为依赖项指定开放范围。开放范围允许解析算法选择满足依赖性要求的最近发布的版本，从而引入新的修复。

最后，对于整个生态需要耗费多少时间来完成漏洞修复，目前也很难评估。在查看了所有公开披露的受影响 Maven 软件包中，安全人员发现只有不到一半（48%）得到了修复。

参考原文：https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html

23 种设计模式实战（很全）

重磅官宣：Redis 对象映射框架来了！！

劲爆！Java 协程要来了。。。

JetBrains 发布下一代 IDE，IDEA 可以扔了

重磅！JDK 17 发布，正式免费。。

面试官：Java 8 map 和 flatMap 的区别？

终于！Spring Cloud 2021 正式发布。。

推荐一款代码神器，代码量至少省一半！

程序员精通各种技术体系，45岁求职难！

重磅！Spring Boot 2.6 正式发布

Spring Boot 学习笔记，这个太全了！

关注Java技术栈看更多干货

获取 Spring Boot 实战笔记！