Apache Logg4j 2.x（以下、Log4j 2）に発見された「Log4Shell」と呼ばれるリモートコード実行の脆弱性が世間を賑わしている。混乱の原因の一つは、Log4j 2に依存するフレームワークやライブラリが大量にあり、影響範囲の特定が難しいことだ。Google Security Blogに公開された次のレポートによると、2021年12月19日の時点で、Maven CentralリポジトリにホストされているJavaパッケージのうち、1万7,000以上のパッケージがlog4j-core（Log4Shellの影響を受けるLog4j 2のライブラリ）を使用してることが判明したという。
Log4Shellは、Log4j 2に搭載されているJNDI Loogupと呼ばれる機能に起因する脆弱性である。この機能を利用すると、ログの出力時にランタイムに対してネットワークを介してリモートから値を渡すことが可能になる。JNDI LookupはデフォルトでLDAP（Lightweight Directory Access Protocol）をサポートしており、外部のディレクトリサービスのファイルにアクセスできるようになっている。
悪意を持った第三者がネットワーク上にLDAPサーバを構築してJavaクラスファイルを配置し、そのURLをWebページの入力フォームやWeb APIなどでLog4j 2が稼働するアプリケーションに送信したとする。すると、アプリケーション側では受信した文字列をログ出力する際にリモートのJavaクラスファイルをランタイムに読み込んで実行してしまう。この仕組みを悪用することで、攻撃者は対象のシステム上で任意のコードを実行できてしまう。
厄介なのは、自分のアプリケーションでLog4j 2を直接使用していなかったとしても、Log4j 2に依存するフレームワークやライブラリを利用している場合は、間接的に影響を受ける可能性があることだ。したがって、影響範囲を正しく把握するには、フレームワークやライブラリの依存関係をすべて調べて、どこでLog4j 2を使用しているのかを特定する必要がある。
-
脆弱性を含むパッケージの依存関係ツリーのイメージ 出典：Google Security Blog
この問題の発覚後に、Googleのオープンソースチームでは多くのJavaプロジェクトによって参照されているMaven Centralリポジトリをスキャンし、Log4j 2に依存するパッケージがどの程度ホストされているのかを調べたという。その結果、全体の約4%にあたる1万7,000以上のパッケージがlog4j-coreの影響を受ける（すなわち、直接もしくは間接的に利用している）ことが分かったとのことだ。依存するパッケージの全リストはcsvファイルとして公開されている。
なお、Google Security Blogでは、検出されたパッケージのうち、約25%は12月19日時点で修正バージョンが提供されていることにも言及されている。
ちなみに、Log4Shellの影響を受けるのは、Log4j 2に含まれる「log4j-core」のjarファイルだけであり、「log4j-api」のみを使用しているアプリケーションは影響を受けないことが分かっている。Google Security Blogの記事では当初35,000超のパッケージが影響を受けると説明されていたが、これは「log4j-api」のみを使用するパッケージも含んだ数字となっている。
Javaのエコシステム全体でLog4Shellの影響が完全に払拭されるには、広大なLog4j 2の依存関係においてすべてのパッケージで修正が完了する必要がある。しかし、Google Security Blogによると、多くのアプリケーションは依存関係ツリーの非常に深い部分でLog4j 2への依存を含んでいるため、このすべてが修正されるには長い月日が必要になる可能性があるとのことだ。
-
コンシューマーの依存関係グラフにLog4j 2が最初に現れる深さのヒストグラム（ただしlog4j-apiも含む）出典：Google Security Blog
なお、本稿執筆時点でLog4j 2の最新版は「Apache Log4j 2.17.0」となっている。当初リリースされた2.15.0および2.16.0における修正では、デフォルト以外の特定のパターン入力に対する修正が不十分であることが判明しているため注意が必要だ。詳細は次の記事を参照していただきたい。
Rustで有名アルゴリズムに挑戦 第17回 RustでHTTPサーバを実装してみよう
