log4j1.x系は大丈夫なの？

はじめに

CVE-2021-44228でlog4jが注目を浴びている結果、log4j1.x系の処置が問題になったので自分なりに周辺事情やらを整理

結論を先に

• log4j1.x系はサポート切れで、今後なんらかの問題が発生しても修正されないので継続利用は問題がある
• とはいえCVE-20221-44228はlog4j1.xには影響なし
• また、既知重大脆弱性CVE-2019-17571についてもSocketServer/SimpleSocketServerいずれかの利用がなければ影響なし
• 上記非該当であれば緊急性はないものの継続利用は問題なのでよく検討して乗り換えましょう

log4j1.x系のサポート

とうの昔に切れている

CVE-2021-44228の危険性

CVE-2021-44228では、log4j2の通常の利用方法においてログメッセージを解析してJNDI探索をしてしまう点が大きな問題になった。

典型的なMessage LookupによるJNDI探索を例にとると
1. PatternLayoutに%m、%msg、%messageの設定でMessagePatternConverterが呼び出される
2. MessagePatternConverter.format(LogEvent, StringBuilder)はStrSubstitutorを利用
3. StrSubstitutorはデフォルトでInterPolatorを利用
4. InterPolatorはログメッセージを解析してJndiLookupを利用
5. JndiLookup.lookup(String)はログメッセージ由来の文字列をJndiManager.lookup(String)をに渡して利用
6. JndiManager.lookup(String)はログメッセージ由来の文字列をjavax.naming.Context.lookup(String)をに渡して利用

上記のように、log4j2では通常の利用方法において、ログメッセージ由来の文字列をjavax.naming.Context.lookup(String)に渡して実行しており、文字列の内容次第ではJNDI探索が始まってしまうという流れ。

CVE-2021-44228と同様の危険性がlog4j1.xにあるか？

log4j1.x系のソースコード
javax.naming.Context.lookup(String)の利用箇所は以下2か所で、いずれもCVE-2021-44228のような重大な問題はなし。

JMSAppender

ソースコード

一瞬槍玉に上がりかけてちょっと有名になったクラス
javax.naming.Context.lookup(String)は呼んでいるが、渡している文字列はtcfBindingNameだったりtopicBindingNameだったり。
要はlog4jの設定由来の文字列で、ログメッセージから自由にJNDI探索させることは不可能。
別の脆弱性を突かれて設定を書き換えられたらどうこうという話もあるが、設定を書き換えられる状況ならすでに色々やられているはずで、CVE-2021-44228と同列に語るようなものではない。

JMSSink

ソースコード

A simple application that consumes logging events sent by a JMSAppender
JMSAppender利用時のコンシューマとして動作する簡易実装？
ともかく、javax.naming.Context.lookup(String)は呼んでいるが、渡している文字列は起動時パラメータ由来のtcfBindingNameやtopicBindingNameなのでJMSSinkも問題ない。

でも既知の重大脆弱性があるって・・

CVE-2021-44228の煽りを食ってる感のあるCVE-2019-17571について整理

CVE-2019-17571とは

Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.

よく判らんがSocketServerというクラスにデシリアライズの脆弱性がある模様
SocketServerはSocketAppender利用時のログ送信先log4jサーバーの簡易実装？

具体的な問題

SocketServer(ソースコード)自体には問題なさげだが
利用しているSocketNode(ソースコード)が受信したストリームのreadObject()を実行している箇所が問題と思われる。

ちなみにSocketNodeはそれ以外にも
SimpleSocketServer(ソースコード)
tests以下のShortSocketServer(ソースコード)
で利用されている。

脆弱性の該当条件は？

tests以下のShortSocketServerは一旦無視するとして、
SocketServer/SimpleSocketServerいずれかを利用していなければCVE-2019-17571の影響は受けない。
とりあえず身近な利用例は知らない。