Log4Shell 2021年 ログの文字列から走るコード

ログに書いた利用者の入力の中の ${...} を、Log4j 2 が置き換えの指示として評価し、JNDI で外の LDAP から読んだコードを走らせた。弱点は1行の直しで消えるが、どこに Log4j があるかを知らない組織は、直す場所を探すところで止まった。

CVE-2021-44228。CVSS 3.1 の基本値は10.0[1][2]。影響は log4j-core の 2.0-beta9 から 2.15.0 の手前まで。ただし Java 7 向けの 2.12.2 と Java 6 向けの 2.3.1 を除く[1]。開発元への届け出は2021年11月24日、公開と修正版 2.15.0 は12月10日[3]。続く修正は12月28日の 2.17.1 までで、開発元は Java 8 以降に 2.17.1、Java 7 に 2.12.4、Java 6 に 2.3.2 を勧める[6][8]。修正は出揃ったが、CSRB は2022年7月に、弱い版は10年かそれ以上残り得ると評した[3]。2026年11月時点の公開資料で書いています。

何が起きたか

• 公開から5日後、Cloudflare は毎秒400回の悪用の試みを観測した[3]。研究者と守る側の走査も多く、悪意のある走査と見分けにくかった[3]。
• CSRB は、報告を書いた時点で、重要な社会基盤への大きな攻撃は把握しておらず、悪用は専門家の予想より少なかったと書く。一方で、悪用の傾向を地域や業種で見渡せる信頼できる情報源は無いとも書く[3]。
• ある連邦の省は、この弱点への対応に33,000時間を使ったと CSRB に報告した[3]。

起きた仕組み

Log4j 2 は、設定やメッセージの中の ${種類:名前} の形を lookup として、その場で値に置き換える。種類の1つが JNDI で、名前に書いた宛先へ問い合わせ、返ってきた物を Java の物として読み込む。2.14 以前は、ログのメッセージに入った値まで既定で評価していた[1][2]。

架空のアプリ。ログに入力を書く、どこにでもある1行

// LoginController.java 架空の例
String user = request.getParameter("user");
log.warn("ログインの失敗 user={}", user);   // 引数として渡しても、2.14 以前は整形後のメッセージを評価した

コードは正しい書き方で、引数として渡している。それでも、整形が終わったメッセージの中の ${...} を Log4j が評価したため、書く側では防げなかった。NVD の説明も、ログのメッセージかその引数を操れる者が、とする[2]。

評価の形 架空の種類の名前で示す。動く文字列ではない

# 受け取った user の値
taro${種類:名前}
# 2.14 以前の既定の動き
1 メッセージを整形する     ログインの失敗 user=taro${種類:名前}
2 ${...} を lookup として探す
3 種類に応じて値を取り、置き換える。種類が JNDI なら、名前に書いた宛先へ問い合わせる
# 2.15.0 以降の既定の動き
1 メッセージを整形する     ログインの失敗 user=taro${種類:名前}   置き換えない

続いた3つの CVE

最初の直しは、既定の設定でメッセージの lookup を止めるものだった。既定でない書式の設定では、別の道で同じ評価に届いた。

どこで止められたか

WAF で悪用の文字列を止める策も広く使われた[3]。lookup は入れ子にでき、同じ意味の書き方が多いので、文字列の照合では漏れる。止まるのは典型の形だけと考える。

守り方

架空の機械 app01 で、ファイルの名前と、まとめた jar の中を探す

find / -xdev -name 'log4j-core-*.jar' 2>/dev/null
/opt/report/lib/log4j-core-2.14.1.jar              # ファイルの名前で見つかる

# 1つにまとめた jar の中は名前で見えない。中の一覧を見る
for j in $(find / -xdev -name '*.jar' 2>/dev/null); do
  unzip -l "$j" 2>/dev/null | grep -q 'org/apache/logging/log4j/core/lookup/JndiLookup.class' && echo "$j"
done
/opt/billing/billing-app.jar                       # 中に JndiLookup がある。版を確かめる

• jar の中に jar を入れた形や、war、ear の中は、この探し方でも届かないことがある。手で探すのは一覧が無い時の間に合わせで、ビルドの時に部品の一覧を出す方が確か。
• 見つけた物は、版、更新した日、責任者、置いた場所と一緒に記録する。CISA の勧告が棚卸しに求めた項目である[7]。

既知の弱点を持つ部品を推移的な依存から見つける考え方は A03 ソフトウェアサプライチェーンの不備 の型1に、入力を命令として評価させない考え方は A05 インジェクション に、ログに書く値の扱いは A09 セキュリティログとアラートの不備 にある。

参照

1. Apache Logging Services security Apache Software Foundation
2. CVE-2021-44228 NIST NVD、2021年12月10日公開
3. Review of the December 2021 Log4j Event Cyber Safety Review Board、2022年7月11日
4. CVE-2021-45046 NIST NVD、2021年12月14日公開
5. CVE-2021-45105 NIST NVD、2021年12月18日公開
6. CVE-2021-44832 NIST NVD、2021年12月28日公開
7. Mitigating Log4Shell and Other Log4j-Related Vulnerabilities AA21-356A CISA ほか、2021年12月22日
8. Apache Log4jの任意のコード実行の脆弱性 CVE-2021-44228 に関する注意喚起 JPCERT/CC、2021年12月11日公開、2022年1月4日更新
9. Apache Log4j Vulnerability Guidance CISA、2022年4月8日更新