【log4j漏洞】log4j 1.x漏洞依赖包解决方案

一 问题描述

log4j 1.x被证实有漏洞,公司要求升级log4j版本到最新,在升级过程中发现问题。对于应用中我们自己写的程序全部替换为新版本。但是在打包发布镜像到harbor时还是被检测出log4j的引用。

二 问题分析 

那么自己的程序中确定是没有引用了,那log4j的引用必定是程序中的第三方依赖包了。于是继续检查本地程序,在pom中一个个的排查依赖包,发现是hadoop相关的包引用到了log4j 1.x,只要添加这几个包中的任意一个,在maven的依赖包中必定会出现log4j1.2.17的架包

【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第1张图片

 【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第2张图片

 于是使用exclusions标签去除对log4j的依赖包

【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第3张图片

添加 exclusions后,maven的依赖包中就不存在log4j 1.2.17的架包了。但是很明显那么去除了log4j的包,那么hadoop那几个包肯定会出现问题,果不其然,虽然编译没有问题,但是在启动springboot的时候,报错了

【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第4张图片

三 解决方案分析

问题出现,第一点肯定是升级hadoop的包,但是目前hadoop的版本是2.x的版本,这几个包都是针对2.x专用的,3.0版本的hadoop包并不一定能用。并且去查了hadoop的官网,发现log4j这个问题正在解决中,还没有完整的可用的包。那么只能想其他办法。

考虑了很久,某时灵光一闪,既然没有log4j的引用类,那么就在程序中创建这些类吧,这样log4j的几个自定义类仍然可以被其他包引用,而应用中又不需要引用log4j的原始包。就这么干!

自定义几个log4j的主要类,保持包名与log4j包名一致,在类中简单实现方法的功能

【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第5张图片

 【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第6张图片

【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第7张图片

 【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第8张图片

 【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第9张图片

 添加这几个自定义类之后,启动springboot成功,功能测试通过!唯一问题,现在并不清楚hadoop的包是否引用了log4j的其他类,这点可以在后续运行中解决或者就是搜索整个hadoop的包去找log4j的引用,都可以解决。

四 候补方案(欺骗方案)

如果觉得上面办法比较麻烦,也并不适合自己的场景,还有一个办法,这个办法只能躲过扫描,并未实际解决log4j漏洞问题,那就是将引入的log4j 1.2.17的包中的版本去改掉,直接修改配置中的版本号,就能躲过扫描。当然这个办法是实在没有办法的办法,下策,骗骗老板而已

【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第10张图片

 【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第11张图片

 【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第12张图片

 【log4j漏洞】log4j 1.x漏洞依赖包解决方案_第13张图片

你可能感兴趣的:(log4j,java,springboot)