log4j 보안 이슈

1. 요란할 필요는 없다.

서버에서 find 명령어로 log4j*.jar 파일을 찾아서 취약점이 발견된 파일들을 최신 버전으로 변경하면 되는 일이다.

Java 7 이하에서는 최신버전을 사용할 수 없으므로, log4j 에서 jndi 기능을 사용할 수 없도록 설정하거나, 여의치 않으면 jar 파일내에서 JndiLookup.class 를 삭제하면 된다.

응용프로그램이 영향을 받을 가능성도 대단히 낮다.

2. 원인

log4j는 "${java:version}" 과 같은 방식으로 로그를 남기면 명령을 해석한 다음 그 결과를 로그 파일에 기록하는 편리한 기능이 있다.

log4j 취약점이란 클라이언트에서 넘어온 파라미터나 헤더를 로그에 남기고 있다면, 클라이언트에서 이 편리한 기능을 간접적으로 이용하여, 서버에서 어떤 기능을 실행할 수 있다는 것이다.

3. 왜 그 동안 발견되지 않았을까?

Java 귀신들이 이 기능이나 소스를 그냥 지나치지는 않았겠지만, 상상력이 미치지 못했을 것이다.

이번 건은 소스코드를 열어 볼 필요도 없고, 기능(jndi)만 정확히 알고 있어도 상상력을 시동할 수 있었을 것이다.

그냥 지나쳤다면 취약점이 발견된 기능이 거의 사용되지 않았기 때문일 것이다.

운영환경(Production)에서 이런 방식으로 로그를 남기는 것은 (로그파일의 크기가 빠르게 증가할 것이기 때문에) 추천되지 않는다.

4. 상념

• 산업계 표준이나 다를 바 없는 log4j 에서도 이런 일이 생길수 있나?
• 어떤 소프트웨어도 취약점이 없는 것이 아니라, 아직 발견되지 않은 것일 뿐.
• 이런 취약점은 기능으로부터 유추할 수 있기 때문에 오픈소스가 아니어도 발견되었을 것.
• 인터넷에서 불특정 다수를 대상으로 한 서비스는 이런 위험을 고려해서 쓸데없는 정보를 서버에 두면 안되는 것.
• 이런 취약점은 악의적인 누군가가 먼저 발견했을 가능성도 있겠지만, 대규모로 공격에 이용되었다면 침입탐지시스템에 걸렸을 것.
• 취약점이 보고되기 전에 log4j를 선택할 것을 비난할 수 없음.
• SQL Injection 은 소스코드를 손봐야 했지만, Java 쪽은 영향이 거의 없었는데, 이번에는 소스코드를 손볼 필요는 없을 것으로 보이지만, Java 만 영향.
• OpenSSL 은 명백한 버그였지만, 이건 버그라고 할 수는 없음.
• 왜 클라이언트에서 넘어온 파라미터나 헤더를 로그로 남기지? 그것도 production 에서?
• 오래된 서버들은 업그레이드를 고려할텐데, 클라우드로 넘어가지 않을까?
• 과거에도 log4j 취약점과 같은 전산쪽의 보안 이슈가 주요 언론에 보도된 적이 있었나?
• 오픈소스는 편리한 기능 따위를 추가하는 방향으로 발전해 왔는데, 이제는 라이브러리의 기능이나 만든 사람의 의도 등도 고찰하고, 공동체가 새로운 기능의 위험에 대해서도 토론해야...