[2021.12] 시절 log4j 보안 취약점 사태가 발생함.
나는 관여된 시스템들 중 log4j을 사용중인 시스템에 대해서 버전업데이트를 해야하는 업무가 주어졌음.
당시 취약점(아래) 취약점들은 높은 수준의 취약점이었기에 상당한 이슈였고 각 시스템을들 업데이트를 하게 되었음.
실질적인 취약점이 발생한 라이브러리는 log4j-core-2.x이고, 대상 시스템 5곳 중 3곳은 log4j-2.x(2점대 버전)를 사용하는 곳이라 그냥 버전만 올리면 되었음.
하지만, 이 취약점 사태로인해 다른버전의 log4j의 취약점도 수면위로 올라온것이 화근...
log4j-1.x의 버전들도 취약점이 존재하는 생태기에 취약수준이 높진 않아도 하는김에 이 취약점을 해결하기로 함.
log4j-1.x을 log4j-2.x로 업데이트하는 것이 쉽지 않았을 것이라고 생각했는데 그 이유가 log4j-1.x와 업데이트 해야할 log4j-core-2.x가 완전히 다른 프로젝트이기 때문..
그래서 조금 찾아보니 log4j-1.x를 log4j-2.x 버전으로 마이그레이션하는 방법을 아파치에서 가이드를 해주고 있었음.
https://logging.apache.org/log4j/2.x/manual/migration.html
요약해보자면, 2가지 방법이 있음.
- 1. log4j-api.jar(브릿지), log4j-core.jar, log4j-1.2-api.jar(브릿지) 세개의 라이브러리를 더 추가해서 코드 수정 없이 마이그레이션하는 방법.
- log4j-2.x-api를 직접 사용하는 방법 (문법차이에 따른 코드 수정 필요)
이 두가지 방법을 예상하고 log4j.1.x를 사용하는 두 시스템을 들여다봄...
시스템을 들여다보니 둘다 Spring기반이긴하나, 하나는 Maven기반 Legacy 시스템이고 하나는 순수 Spring으로 구성되어 있었음..
먼저 금방 할 수 있을거라고 생각한 maven기반 프로젝트의 라이브러리를 살펴보니, slf4j-api와 slf4j-log4j12라는 라이브러리를 사용하고 있었고 slf4j-log4j12에서 log4j를 직접적으로 의존하고 있었음.
구조를 조금 살펴보니 slf4j-log4j12가 slf4j-api의 구현체였고 소스코드에서는 slf4j-api라이브러리의 인터페이스만 사용중이었음. (인터페이스의 중요성, 필요성을 다시 한번 깨닫는다.....)
그래서 아파치에서 가이드하는 log4j 1.x마이그레이션 방법은 다른 직접사용한 라이브러리를 뜯어고치지 않는 이상 쉽게하기 힘들어보였고, slf4j-api의 인터페이스를 구현한 구현체들을 찾기 시작함.
아니나다를까, slf4j-simple, slf4j-jdk14, slf4j-nop, slf4j-jcl 등을 mvn repository에서 찾았지만 log4j기능을 대체할만한게 없다고 생각할 때, logback도 slf4j-api을 구현한 구현체가 있다는 것을 발견했다.
그것이 바로 springboot에서도 사용하는 logback-classic!! 직접적인 취약점은 없기에 이걸로 구현체만 변경하면 log4j.xml등 설정파일 말고는 코드수정 하나 없이 취약점 보완이 가능했다. (log4j-2.x.x를 사용하려면 java, tomcat버전도 맞췄어야 헀다는....)
그렇게 maven기반 legacy프로젝트의 취약점 보완은 해결하였으나, 순수 Spring으로 되어있는 시스템은 slf4j-api등 인터페이스를 사용하지 않고, log4j.1.2.16라이브러리를 직접 바라보고 있어서, 위의 slf4j-api와 logback-classic을 이용하여 로깅하는 것으로 전체 로깅 코드를 일괄 수정하여 보완하였다...
끝.
Thank you!
