log4j 취약점 발견! 빨리 패치하라!

마인크래프트에서부터 난리난 엄청난 취약점이다. 심지어 이미 공격 정황도 많이 포착됐다.
게다가 이거 안 쓰는 시스템이 해외에서는 없을 정도로 큰 충격에 휩싸였다.
한국이라고 안심할 이유는 없다. 만약 지체할 시간이 없다면, 내가 몇 가지 패치 방법을 제안한다. 나를 따르라!

(2021-12-16) 바빠 죽겠는데 log4j 1.2 쓰는 시스템 또 찾아내야돼? 그리고 2.15.0 또야?

log4j를 2.16.0 으로 올려라!

사실 2.15.0은 아직 정식 릴리즈가 아니다. 하지만 JDNI를 포기할 수 없는 특수한 환경이라면...(근데 그럴 일 없을 것 같은데?)
일단 쿨하게 그냥 올려라. 가장 간단하고 손이 덜 가는 방법이다. 2.15.0 이전에는 항상 대응해야 하는 거 그냥 maven이나 gradle 로 세팅만 하면 그만이고, jar 파일 갈아끼우면 된다.
하지만 안심하던 2.15.0 버전에 또 취약점이 발견되어 결국 2.16.0 나왔다. 그래서 결론은? 2.16.0 올려라. 더 올리라고.

<properties>
    <log4j2.version>2.16.0</log4j2.version>
</properties>

ext['log4j2.version'] = '2.16.0'
// or
implementation(platform("org.apache.logging.log4j:log4j-bom:2.16.0"))
// or
configurations.all {
	resolutionStrategy.eachDependency { DependencyResolveDetails details ->
		if (details.requested.group == 'org.apache.logging.log4j') {
			details.useVersion '2.16.0'
		}
	}
}

벨로그야 그루비 구문강조 안 된다 빨랑 고쳐라.

자바 8 이상이라면 이게 끝이다. 하지만 운영 시스템이 자바 8 미만이라면... 못 한다. 2.15.0 은 자바 8 이상이어야 하기 때문이다. 하지만 그렇다고 희망을 버린 건 아니다. 계속 따르라!

log4j2.formatMsgNoLookups 시스템 속성을 true로!

그냥 자바 실행 인자에 이런 식으로 추가하면 된다.

java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar

아니면 main 메소드에 System.setProperty 메소드로 추가하든, 어떻게든 저게 적용되면 된다.
그리고 가동절차서에 따라 재가동 하면 된다. 톰캣 같은 서블릿 컨테이너 기반 서버는 각 컨테이너에 인자를 넣는 메뉴얼을 따르라.
이 옵션은 log4j 가 2.10.0 이상이면 사용 가능하다. 그 미만이면? 괜찮다. 나를 계속 따르라!

PatternLayout 설정 문자열에 %m{nolookups} 포함

어찌보면 위 방법보다 더 쉬울 수는 있을 것이다. 그렇다고 재시작 해야 하는 건 변함없지만.
어자피 log4j 를 쓴다면 로그 패턴을 세팅하는 건 당연하다고 생각할 것이다.
어자피 로그 메시지는 뿌릴 것이다. %m 부분 보이는가? 그걸 %m{nolookups} 로 바꾸면 된다.
별거 없지?

이 옵션은 log4j가 2.7.0 이상이면 사용 가능하다. 그 미만이면? 이거 절망적이네.. 일단 나를 따르라...

log4j-core.jar 까버리기

JdniLookup 클래스와 JdniManager 클래스가 있다. 이들을 멍청이로 만드는 게 목적이다.
log4j 를 직접 빌드하겠다면, 위 클래스를 바보로 만들어 빌드 후 배포하면 되고,
자신없다면, 위 클래스를 직접 앱에 패키지 맞춰서 추가하면 자바는 네 앱의 클래스를 우선적으로 읽어들여 바보로 만들어줄 것이다.
이 방법은 log4j 2.0.0 이상이면 모두 적용 가능하다. 가장 지저분하고 어려운 방법이지만.

보호나라가 매우 좋은 팁을 줬다. 아래 명령어로 주요 클래스 파일을 없애버릴 수 있으니 jar 까버려 관리하면 된다.

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

log4j 모듈을 패키지 매니저에서 로컬로 관리하는 등 수동 관리해야 하는 단점이 있지만 지금 사태에 비하면 이게 최선이다.
근데 이게 jar 무결성 확인하는데 이게 먹히나 고민되기는 하지만... 정부 공식이니 검증 당연히 했을 터. 걱정 말고 KISA를 따르라.

log4j 1.2

전자정부 등의 옛날버전 쓴다고 안심하던 개발자들 대가리 콩 하고 시작하자. 보호나라에서 CVE-2021-4104 내용이 추가되었다.

조치 방법이 있는데, 이건 정말 까버리는 방법밖에 없다. config도 없다. 절망적이지만 이렇게라도 해야 한다.

zip -d log4j-1.2.*.jar org/apache/log4j/net/JMSAppender.class

log4j 포기

일단 한국 업계 표준 프레임워크인 Spring일 경우,(전자정부프레임워크라고 한 놈 뒤지고싶냐?)
slf4j 기본 구현체가 기본 로깅 모듈일 것이다. 그래서 다들 logback 쓸 거다. 그래서 별도로 log4j 로 바꾸는 수고가 없다면 별 걱정 없을 것이다.
하지만 그렇다고 log4j 를 종속성으로 추가한 모듈이 있으면, 말짱꽝이다. log4j 종속된 모듈 찾아서 위 방법을 적용해야 한다.
왠만하면 해당 모듈에서 다른 로그 모듈을 바꾸는 속성을 제공할 것이다. 어떻게든 포기하라. 그러면 피할 수 있을 것이다.

끗. 급조해서 쓴 거라 좀 웃기는구만.

출처:

• CVE-2021-44228: Proof-of-Concept for Critical Apache Log4j Remote Code Execution Vulnerability Available (Log4Shell)
• Log4J2 Vulnerability and Spring Boot