[세무민의 IT 소식] : Log4j 신규 취약점에 따른 이슈

기존에 포스팅 했던 Log4j에 대한 내용은 아래의 포스팅에서 확인할 수 있습니다.

 

[세무민의 IT 소식] : Log4j 취약점 관련 내 생각 및 리뷰

---

이번에 다룰 내용은 최근에 이슈되어서 log4j 2.15 이상으로 사용하라는 해결방안이 나왔지만 

최근에 다시 취약점 "CVE-2021-45105"가 나온 상황이라 버전 업을 다시 해야만 합니다.

 

취약점 확인

우선 CVE-2021-45105를 확인해보면 ${lookupName:key:-defaultValue}라는 조회 패턴을 가지고 있다. 

1. lookupName : 이름 및 유형(Ex -> CTX,ENV 등)

2. key : 해당 맵 객체에서 찾을 수 있는 변수의 이름을 말함(Ex CTX -> ThreadContext)

3. defaultValue : 키가 맵에 존재하지 않는 경우에 대체 값을 말함 

만약 위의 구조에서 ThreadContext맵의 변수가 공격자가 제어하는 경우라면 기본값을 통해 컨텍스트 조회와

동일한 문자열을 보유할 수 있게 된다.

---

%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} – %msg%n ${ctx:user}

그리고 ‘layout pattern’을 설정하는 상황에서 취약점이 발생할 수 있다고 한다.

 

${ctx:user1:-${ctx:user}}

애플리케이션 사용자가 ThreadContext 맵에 저장된 사용자 변수를 제어할 수 있다고 가정하면

공격자는 user 값을 위와과 같이 설정하고 스택 오버플로를 유발할 수 있습니다.

위의 변수로 작동 패턴을 보면

1. 대리자가 컨텍스트 맵 내에서 user의 값을 찾아서 user를 대체합니다. 

2. 그런 다음 user의 값이었던 결과 조회 패턴을 평가하려고 할텐데 해당의 경우는 user1이 ThreadContext에 존재하지 않기 때문에 대리자는 최후의 수단으로 기본값으로 진행합니다. 

3. 따라서 구성 레이아웃의 패턴이 원래 조회와 동일하다는 점에서 대체자가 스택 버퍼가 오버플로우 될 때까지 대체 메서드를 계속하여 호출하는 상황이 생길 수 있다. 

 

결론

따라서 log4j에서 조회 시 재귀를 제한해야 하는데 이러한 문제를 Apache에서 완화하기 위해

2.17버전을 출시했고 해당 버전은 현재까지 조회 값 자체에서 발생하는 재귀 조회를 방지하는 기능을 가집니다. 

 

해결방안

해결 방안으로는 log4j 2.17.0 이상의 버전을 이용하는 방법이다.

만약에 패치하기 어려운 상황이라면 Layout Pattern에서 ${ctx:loginId} 또는 $${ctx:loginId}를 제거하거나 (%X,

%mdc, or %MDC)로 변경해야 한다.

 

느낀점

현재도 취약점에 따라 370만건 이상의 악용하는 사례들이 계속 존재해서 버전업을 하는것은

우선시 되어야 한다고 생각한다.

실질적으로 log4j를 사용하지 않을 수 없기 때문에 더더욱 조심해야 하며 만약의 상황을 대비하여 

 log4j 스캔 도구를 통해 취약점을 빠른 시간내로 확인하는 것도 해결 방안 중 하나라고 생각한다. 

 

참조
https://www.whitesourcesoftware.com/resources/blog/log4j-vulnerability-cve-2021-45105/
https://www.boannews.com/media/view.asp?idx=103443