[市場動向]

2021年12月20日(月)日川 佳三（IT Leaders編集部）

リスト

　Apacheソフトウェア財団は、Java言語向けのログ出力ライブラリ「Apache Log4j」の新版「2.17.0」（Java 8用）を、2021年12月17日にリリースした。前々版「2.15.0」（12月6日リリース）と前版「2.16.0」（12月13日リリース）に続き、2週間ほどの短期間に、それぞれ見つかった脆弱性を修正したバージョンをリリースしている。

　前々版の2.15.0では、攻撃者が用意した任意のJavaコードを実行してしまう脆弱性（CVE-2021-44228、通称：Log4Shell）に対処した。前版の2.16.0と今回の2.17.0では、同脆弱性に関連した別の脆弱性（CVE-2021-45046、CVE-2021-45105）にそれぞれ対処している。

ライブラリを修正版に更新できるなら更新すべき

　ユーザーは、Log4jライブラリを自力で更新できる環境にあるならば、更新することが望ましい。脆弱性の内容や脆弱性への対応状況は、Apacheソフトウェア財団のLog4j公式ページ（画面1）で確認可能であり、脆弱性に対応した現行バージョンもここからダウンロードする。

画面1：Log4j公式ページのWeb画面
拡大画像表示

　ダウンロードページでは、Linux環境に向いたtar.gzファイルと、Windows環境に向いたZIPファイルのいずれかの形で入手する。入手したtar/zipアーカイブを展開すると、Javaライブラリをまとめた複数のJARファイルを得る。脆弱性があるJARファイルは「log4j-core-*.jar」（バージョン2.14.1ならlog4j-core-2.14.1.jar）である。新しいバージョンのJARファイルをシステムに配置し、クラスパス（ライブラリの参照パス）を設定する。

　JARファイル「log4j-core-*.jar」自身もZIPアーカイブである。このJARファイルを構成するクラスファイルのうち、脆弱性を持つものは「JndiLookup.class」である。JARファイルを新版へと更新できない場合は、現状のJARファイルからJndiLookup.classを削除する、というやり方もとれる。ZIPコマンドなどZIPを扱えるプログラムを使ってJndiLookup.classを削除する。

　ライブラリの更新や削除ができない場合は、ネットワークのアクセス制御（ファイアウォール設定）で対処する。例えば、入り口対策として、Javaアプリケーションサーバーに対するHTTPリクエストに脆弱性のトリガーとなる文字列が含まれていた場合、これをブロックする。出口対策として、該当のJavaサーバーから外部サーバーに対するアクセスは、ホワイトリストで指定したものを除いて遮断する。インターネット上のLDAPサーバーにアクセスさせないことで脆弱性を薄める。

Log4jを使っているかどうかが分かりにくいのが問題

　バージョン2.15.0で対応した脆弱性（CVE-2021-44228、通称：Log4Shell）は、大きな話題になった。主な理由は2つある。1つは、脆弱性の内容が、任意のJavaコードを実行してしまうというクリティカル（致命的）なものだということ。もう1つは、Log4jはJavaのログ出力ライブラリとして一般的であり、多くのJavaソフトウェアやアプライアンス機器が利用していることである。

　Javaアプリケーションサーバーを自前で構築して運用しているユーザーは、今回の脆弱性にも対処しやすい。脆弱性を修正した最新版のLog4jをダウンロードして置き換えればよい。システムがLog4jを使っているかどうかも、比較的調べやすい。デバッグツールや脆弱性調査ツールなどを使えば、ソフトウェアやライブラリ同士の依存関係も調べられる。

　今回の脆弱性に関して厄介な点は、どの製品がLog4jを直接的または間接的に使っているのかが分かりにくいことである。例えば、ベンダー製品が今回の脆弱性の影響を受けるかどうかは、ユーザー自身では分かりにくく、ベンダーサポートからのアナウンスによって知ることになる。場合によっては、ベンダーが修正パッチを出したり、脆弱性の回避策をアナウンスしたりする。

　第三者による情報発信の取り組みもある。例えば、NCSC-NL（オランダ政府のサイバーセキュリティセンター）は、個々のベンダー製品が脆弱性の影響を受けるかどうかをまとめて公開している。脆弱性の影響を受けるか、問題を修正しているか、などの情報が得られる。

●Next：Log4j脆弱性の概要と修正点