mutao.net

いわゆる雑記。

log4j2の脆弱性についてのポエム

災害レベルの脆弱性に出会ったので記念?に書く。

ゼロデイ脆弱性だし、日本は金曜日だし最悪なタイミングでした。

logging.apache.org

Base CVSS Score: 10.0 と文句なしの満点。

loggerにこのレベルの脆弱性があるとは考えもしてなかった。

www.lunasec.io

私が気づいたのはluasec社のpost。というかそれが拡散されて届いた形になる。

2.0 <= Apache log4j <= 2.14.1 のバージョンで特定の文字列(jndi)を変数として置換(Lookup)することで任意のコードを実行できる。

log4j2が出力したログ全てが対象なので攻撃が容易。404でも500でもHTTPリクエストさえ通ってログに出力できればよい。

脆弱性が報告された段階では JVMの起動オプションに LOG4J_FORMAT_MSG_NO_LOOKUPS=true を追加する(2.10以降)みたいな対策が取られてました。

現在ではlog4j2 2.15.0が maven repositoryに上がっていて、バージョンアップが勧められてます。

mvnrepository.com

log4j 1.xはどうなのか?

今回の脆弱性では影響は受けないみたいでした。というかそもそも別物。

github.com

ceki氏によると1.x系ではLookup機能が提供されていないため、変数ではなくそのまま文字列としてJMSに送られるとのこと。

ただ、すでにサポート終了しているし、下記のような脆弱性があるので許容している状態で危険。

www.cvedetails.com

// 2021/12/12追記

ceki氏も以下のようにコメントしています。

jpcertでも脆弱性の報告上がっていました。

Tweetを見る限り、2021/11/21の15:00頃かな。

休日にjpcertが動く印象がないので少し驚きました。

www.jpcert.or.jp

Twitter見てて思ったこと

SLF4J + logbackだから平気だったみたいなツイートが結構ありました。

SLF4Jは開発止まっているしあんまり使わない方がいいよね。みたいな風潮があったと思っていたので少し驚きです。

ちなみに開発は止まっていないというか再開されてます。

github.com

AWS

AWS WAFでブロックする機能が公開されました。早い。

dev.classmethod.jp