「Log4j 2に脆弱性があるらしい、バージョンアップしたら治るらしい。」
本日話題のこのテーマで軽く書いておきます。 未完です。
未完公開の言い訳。更新した内容は最後に書いてます。大きな間違いは（今のとこ）ないので、よかった。
2021-12-20追記: 2.17.0 出てますのでコピペしてそのままにせず適宜読み替えてくださいね。
とにかくバージョンを上げよう
……リリースできるかは別の話として。 バージョンを上げられないことには話になりません。ということでとにかくあげましょう。
Log4j 2のようなログライブラリは多くのプロダクトで使用されています。 意識する／しないに関わらず、ログライブラリは何かしら関連があると思うべきでしょう。
使用しているかの調べ方
常時依存ライブラリリストを出力するなどして管理しているのであればそれを見ればいいだけの話ですが、そうでなければ、 mvn dependency:tree（使ってるかだけなら mvn dependency:list の方がいいかもだけど） や gradle dependencies を叩いて log4j ワードを見るのが汎用的で取り早いでしょう。
プロダクトがたくさんあるなら、シェルスクリプトとかでやるといいかもですね。
出てこなかったら終了ですが、まず何かしら出てくると思います。
今回の話だと log4j-core が対象っぽい（log4j-apiだけなら影響ないんじゃ？と思ったりはしてますが調べてないです）ので、log4j-coreが無いならあげないのもありかもしれませんが、「Log4j 2は一部使っていますが、log4j-to-slf4jだけなんで上げなくていいんです」みたいな説明はそれはそれで面倒なので、一律「使ってるので更新しました」というのもありかなって。
「pom.xmlやbuild.gradleに書いていないから使っていない」は誤りです。
ログライブラリの構造
Javaのそれなりの規模のアプリケーションは、歴史的経緯もあり、このような構造になっています。
この図ではログAPIが3種類ありますが、必要なだけ用意して、それを一つのロガー（実際にログを書き出すもの）に流し込む構造です。 これにより、異なるログAPIを使用しているライブラリやフレームワークでも共存できるようになっています。
色を塗っているところが依存ライブラリです。 自分達のコードが使用しているのは一番左だけですが、全てなければ実行時エラーになってしまいます。
下半分の色を変えているのは、ログライブラリが環境（アプリケーションサーバー）に提供される場合があるため。 今回のアップデート対象は「ロガー」のところなので、冒頭に挙げた「挙げなくていい」や、デフォルトではログAPIだけLog4j 2を使用しているSpringBootがLog4j 2に変えてなかったら影響ないよと言っているのはこのためです。
Spring Boot users are only affected by this vulnerability if they have switched the default logging system to Log4J2. The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages are vulnerable.
このアナウンスが出たので慌てて上げなくていいところは多そう。
上記の構造のため、本エントリなどの「バージョンアップ」は、providedの場合には通用しません。 アプリケーションサーバー側での対応が必要になると思います。（最近アプリケーションサーバー使わないから詳しくはわからない。）
どうでもいいけどcompile or providedじゃなくruntime or providedのが適切だと思うけど、大勢に影響ないし、画像直すの面倒だから直さない・・・。
ログライブラリの構造のもう少し詳しい情報は以下が参考になると思います。
- Javaのログ出力: 道具と考え方: 宮川拓さんのスライド
- SLF4Jのユーザーマニュアル: の画像がわかりよい
- Log4j 2のFAQのJARの関係: 今回はこっちの画像の方がいいか。
バージョンアップのやり方
Log4j 2は複数のjarで構成されます。
MavenCentralRepositoryにあるものは https://search.maven.org/search?q=g:org.apache.logging.log4j で見られ、このブログを書いている現在、57個あります。 2.15.0 がリリースされているもので29個。いちいち見ていられません。
こういう複数jarのライブラリはBOMと呼ばれるバージョン管理用の一式が提供されていたりします。BOMはBill of Materials（部品表）のことで、Mavenでも公式に使用されている言葉です。
Log4j 2も log4j-bom があるので、これを使います。
MavenだとdependencyManagementタグです。
<dependencyManagement> <dependencies> <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-bom</artifactId> <version>2.15.0</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>
Gradleならplatformです。
dependencies {
implementation platform('org.apache.logging.log4j:log4j-bom:2.15.0')
}
BOMを使用するとバージョンがこちらで管理されるので、log4j-api などを直接dependencyに追加する場合などもバージョンを記述しません。
仮に記述しても新しいバージョンが優先される（Gradleの競合解決に依存する）ので注意が必要です。
注意: log4j-apiなどの個別バージョンを指定してはいけない
すべてのLog4j 2ライブラリのバージョンを指定したりその違いを担保できないのであれば、個別に指定してはいけません。
たとえば以下のように記述した場合
dependencies {
implementation 'org.apache.logging.log4j:log4j-api:2.15.0'
// ...他にもある
}
こんなことになったりします。
Log4j 2のバージョン食い違い。運良く動作すればよいですが、メソッドシグネチャの変更などがあると実行時にメソッドが見つからない例外が出たりします。辛い。
SpringBootでのバージョンアップ
公式アナウンス見た方がいいかも。（書いてること同じだけど）
SpringBootを使う場合、意識しているかはさておき spring-boot-dependencies を使用しているはずです。
spring-boot-dependencies のソースはGradleだったりするんで、pomファイル を見た方がイメージしやすいでしょう。
Gradleを使っててもMavenの知識が必要になってくるのはこういうところ・・・。
バージョンを上書きすると、「SpringBootチームが検証していくれているバージョンの組み合わせと違う組み合わせ」を使うことになります。 もちろん上書きしなくても動かない可能性はあって、自分達の責任範囲ではあるのですが、より動かない確率が高まるのは事実です。 SpringBootに乗っかるのであれば、この辺りのバージョン上書きはしないに越したことはない、と思っていたりします。
2021-12-23にリリースされるSpringBoot 2.6.2 でLog4j 2の2.15.0を使うようになってくれるようなので、もし今回の対応で上書きしても、SpringBootのバージョン上げる時は忘れずに削除するようにしましょう。
でないとLog4j 2が古いバージョンに取り残される可能性が出てきます。
バージョン上書きに関する警告はSpringBootのリファレンスにも書かれています。
Each Spring Boot release is designed and tested against a specific set of third-party dependencies. Overriding versions may cause compatibility issues and should be done with care.
SpringBoot x Maven
Mavenの<properties> タグでバージョンが列挙されていて、これで使うバージョンを上書きできるようになっています。log4j2.version でテキスト検索してもらえれば log4j-bomが使用されているのがわかるかと思います。
（なんで log4j-to-slf4j も入ってるんだろ・・・何かとかちあってるのかな？他のBOMに入ってるのよりトップレベルで書いてるののほうが優先されたりする。）
なのでSpringBootをMavenで使用している場合などは、propertyを上書きするのが正道です。pom.xmlに以下のように書く。
<properties> <log4j2.version>2.15.0</log4j2.version> </properties>
もしくはmvnコマンドのパラメタでも指定できます。バージョンアップを一時的に試したいとかならパラメタのが楽と言えば楽かもですね。
SpringBoot x Gradle
SpringDependenctManagementプラグインを使用している、要するに apply plugin: 'io.spring.dependency-management' と書いているなら、Mavenと同じプロパティが使用できます。
つまり、 ext['log4j2.version'] = '2.15.0' をbuild.gradle に書いてあげればOKかと思います。
SpringのDependencyManagementPluginを使用していない場合については別に書きました。（2021-12-11T22:40）
脱線: 「Mavenリポジトリ」の指すもの
MavenCentralRepositoryは何も設定しなければデフォルトで使用されるリポジトリと思っていただければOKです。なにも修飾せず「Mavenリポジトリ」と言えば、MavenCentralRepositoryを指します。
よりダイレクトに見るならば https://repo1.maven.org/maven2/org/apache/logging/log4j/ です。こちらになければ、リポジトリを明示的に指定するかローカルリポジトリに自身でインストールしない限り、 mvn コマンドで使用できません。
なお https://mvnrepository.com/ はMavenCentralRepositoryを含めたMavenリポジトリを横断的に検索する、個人が運営してくれているサービスです。
irof.hateblo.jp もう少しくわしくかきました。
検証とかリリースとか
2.15.0 に更新することで、なんらかの互換性を失っているかもしれません。最近はあまり踏みませんが。
今回は2.14.1 から 2.14.2でなく2.15.0 なので、そこそこ大きな変更が予想されます。
互換性を失っている場合、直接使用している部分はコンパイルエラーになりますが、大抵はそうではなく、使用しているライブラリが使用しているメソッドが無くなってたりシグネチャが変わっていたりなどです。
こういう時は実行時に NoSuchMethodException とかが出てきます。困る。
でもいちいち調べるの無理なんで、自動テストで担保しましょう。
動作レベルの検証はユニットテストでいけますが、ログライブラリは環境による出力に差があるもの（ユニットテストならコンソールにプレーンなテキストで出すけど、運用環境だとJSONで出したり、ファイルに出したり）なので、ユニットテストだけでは担保できません。 ログを監視する仕組みも含めた環境に乗っけてのテストが必須になってきます。
また、当然のように性能にも差が出てきます。 この辺りのテストも自動化しておくと、「負荷テストぶん回しながらリリースに関わる説明とか調整を行う」ができたりします。
あと本番環境へのリリース後もしばらくは検証とみなせます。 Blue/Greenデプロイなどで切り戻せるようにしておけば、負荷テストを回しながら（致命的な問題があったら戻す）、セキュリティリスクの高い状況を早期に脱するためにリリースをしてしまう。なんて選択肢も出てきます。
申し送り（2021-12-10T18:00）
ちょっと用事があるので、推敲もしていませんが公開しておきます。あとで追記したり、ガラッと書き換えるかも。
