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

一 问题描述

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

二 问题分析 

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

 

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

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

三 解决方案分析

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

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

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

 

 

 

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

四 候补方案（欺骗方案）

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