log4j2 취약점 해결 과정

얼마전 아파치 재단의 log4j2 모듈 취약점이 발표되었다.

[1] Apache Log4j Security Vulnerabilities

https://logging.apache.org/log4j/2.x/security.htm

[2] CVE-2021-44228

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

[3] CVE-2021-45046

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

[4] CVE-2021-4104

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104

CVE - CVE-2021-4104

 

내가 담당 중인 시스템은 log4j 1.2.x 버전대를 사용 중이서 다행히(?) 위 취약점 이슈를 피해가는 듯 했다.

 

하지만 1.2.x 버전대를 적용 중인 시스템도 업그레이드 미지원 및 취약점 노출가능성에 따라 KISA에서 업그레이드 권고를 내렸다.

https://www.krcert.or.kr/data/secNoticeView.do?bulletin_writing_sequence=36389 

KISA 인터넷 보호나라&KrCERT

 

따라서 사내 레거시 시스템을 log4j에서 log4j 2.16으로 마이그레이션 해야했다.

간단히 소스코드에서 log4j 라이브러리 및 소스를 걷어내고 새로 적용하면 되는가 싶었으나,

문제는 자체 프레임워크(struts와 결합한) 내 로거 인스턴스를 반환하는 API가 정의되어 있었다.

전체 소스 구석구석 해당 API를 호출하여 log4j를 사용하고 있었고, 해당 API는 클래스 로더에서 인스턴스를 만들어 메모리로 올리는 구조였다.

결국 log4j를 걷어내려면 프레임워크 수정이 불가피했고,

이렇게 된 김에 전체 소스를 수정하지 않고 로거를 호출하는 API 인터페이스는 유지한채

프레임워크 API만 수정하는 것으로 방향을 잡았다.

 

과정을 서술하기 전,

아래는 log4j2로 이관하면서 내가 도움을 받은 사이트들이다.

https://stackoverflow.com/questions/48115143/log4j-1-2-propertyconfigurator-log4j2

Log4J 1.2 PropertyConfigurator -> Log4J2

https://developyo.tistory.com/162

[log4j] log4j.xml 설정 : Logger 위계구조, 로그 분리하기

https://okky.kr/article/278933

OKKY | log4j 설정시 -D 자바 환경변수에서 설정된 값을 읽어올수 잇나요?

https://mkyong.com/logging/log4j2-xml-example/

log4j2.xml example - Mkyong.com

 

먼저 사내 프레임워크 jar파일을 풀어헤치고,

로거 관련 API있는 부분만 디컴파일링하였다.

디컴파일링된 패키지 내부를 들여다보니, 생성자에서 프레임워크home과 설정파일을 조합하여 Application 기동 시 바로 로거 인스턴스를 메모리에 올리고 있었다.

그렇다면 핵심은 2가지이다.

1. log4j의 로거와 log4j2의 로거는 호환이 되는가?

2. log4j의 인스턴스 생성과정과 log4j2의 인스턴스 생성과정은 동일한가?

 

1번은 OK였다. 다행히 패키지 및 getLogger가 정의된 클래스명만 다를뿐 getLogger로 얻어진 인스턴스로 동일하게 재사용이 가능했다.

2번은 조금 달랐다. 아파치 재단에서 log4j-1.2-api-2.16.0.jar 라는 브릿지로 1.2.x의 API 일부를 지원하고있었으나,

내가 적용하려는 log4j-api-2.16.0.jar 및 log4j-core-2.16.0.jar에는 1.2.x에서 사용하던 PropertyConfigurator라는 클래스가 없었다.

구글링해보니, 2버전에서는 xml로 설정파일을 불러들이도록 변경된 상태였다.

log4j-1.2-api-2.16.0.jar 브릿지를 이용하여 PropertyConfigurator 살리는 방법도 있었으나, 이건 2안으로 미뤘다.

 

스택오버플로우와 여러 블로그의 도움을 받아 마이그레이션 하였는데, 주요 변경 점을 아래와 같이 공유한다.

주요 변경 점

설정자체도 properties에서 xml로 마이그레이션하는 것에 상당히 애를 먹었지만, 위 링크된 사이트에서 많은 도움을 받아 해결하였다.

이렇게 수정하여 logging패키지만 다시 컴파일 한 후 jar를 업데이트하였다.

결과는 성공!

2안이었던 브릿지를 사용하지 않아도 될 것 같다.

괜히 1.2API를 살려놨다가 브릿지 지원이 끊긴다거나, 브릿지를 사용함으로써 겪게 될 추가 이슈가 염려되었는데 그럴 필요 없이 깔끔하게 해결되어 다행이다.