Apache Log4j 漏洞影响有多大?

共 1613字,需浏览 4分钟

 ·

2021-12-28 15:16

点击关注公众号,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 实战笔记!
浏览 29
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报