Log4j Log4Shell 脆弱性に関する Q&A

最近開催された JFrog ウェビナー Log4j Log4Shell Vulnerability Explained: All You Need To Know にて、 シニアディレクターの Shachar Menashe （シャチャー・メナシェ）は、このセキュリティ問題とその検出・修正方法に関する情報を共有しました。

今回のウェビナーで寄せられた質問をもとに、以下の Q&A で追加情報をご紹介します。

Log4j のセキュリティ問題

log4j のエクスプロイトはいかにして成し遂げられるのでしょうか?

JFrogは、この脆弱性を詳細に説明した包括的なブログを公開しています。
「Log4Shellの脆弱性の原因は何か?」のセクションをご覧ください。

log4j の API コールも脆弱であると聞きましたが、JFrog ではなぜコアだけに注目しているのですか？

log4j-api は脆弱ではなく、log4j-core のみが脆弱です。

log4j の log4shell 脆弱性は、Shellshockと比較して世界的な影響はどうですか？

log4shell と Shellshockは、どちらも膨大な範囲のシステムに影響を与えるリモートコード実行の脆弱性です。Shellshockは、アプリケーションである bash（Linux のごく一般的なシェル）の脆弱性であり、log4shell は log4j ライブラリの脆弱性です。いくつかの理由から、log4j のセキュリティ問題の方が、脅威を軽減する観点からは大きな課題となっています。

Shellshock を検出するには、脆弱なバージョンの bash がインストールされているかどうかをローカルシステムで確認するだけで十分でしたが、bash 自体は通常サードパーティの依存ファイルと一緒には出荷されません。

log4shell のセキュリティ問題を検出するのははるかに困難です。log4j はライブラリであるため、検出にはすべての直接および間接（推移的/再帰的）依存関係をチェックする必要があります。さらに、log4shell の攻撃ベクトルは、Shellshock の攻撃ベクトル（未解析の入力を bash 環境に渡す）よりも一般的（未解析の入力を記録する）です。

更に、log4shell は修正が困難です。log4shell はライブラリなので、いくつかの API が新しいバージョンで変更されています。これは、ソフトウェア ベンダが、log4j 自体をアップグレードするだけでなく、log4j と直接やりとりするファーストパーティ コードを修正しなければならないかもしれないことを意味します。

そして、log4j のより新しいバージョンは、より新しいバージョンの Java（従来の Java 6/7に対してJava 8）を必要とします。これは、ソフトウェア ベンダが同様に Java コンポーネントをアップグレードしなければならないかもしれないことを意味し、それは、システム上の他の Java ベースのソフトウェアとの互換の問題を起こすかもしれません。

脆弱でない log4j バージョン１についてはどうでしょうか？log4j バージョン２の注目度の高さの影響を受けるでしょうか？

現在のエクスプロイトは、バージョン１を危険にさらしません。しかし攻撃者は、追加の脆弱性を見つけようと、log4j コンポーネントの調査に今より多くの努力をするかもしれません。

Log4j の検出とその修正ソリューション

リポジトリに log4j パッケージがあるかどうかを判別するツールはありますか？

はい、あります。まず、ミッションクリティカルなソフトウェア開発ライフサイクル（SDLC）プロセスの中心的な部分として JFrog DevOps Platform を使用している JFrog のお客様は、log4j の脆弱性に対して素早く修正するために必要なすべてをすでにお持ちです。

Artifactory のバイナリ リポジトリ管理下で蓄積されたパッケージ、バイナリ、イメージ、メタデータを使って、アーティファクトやビルドを検索し、ソフトウェアのサプライチェーン全体で、推移的な依存関係を含む log4j パッケージのあらゆる用途を発見することができます。またXray ポリシやウォッチを作成して、log4j パッケージの脆弱なバージョンを使用しているビルドをプロダクションへリリースされることを防止することができます。

広く開発者コミュニティのために、さらにJFrog は、ローカルディレクトリ内のソースコードとバイナリの両方で log4j の使用を判定する有用なオープンソースツールのセットをリリースしました。

log4j のコンパイル時依存性を持っているサードパーティ コンポーネントを使用したい場合、log4j を取り除く方法はありますか？

これは、パッケージが log4j の脆弱なバージョンを使用している場合にのみ問題となります。その場合は、サードパーティ製コンポーネントの修正版を入手する必要があります。ソースコードがあれば、修正された log4j のバージョンで自分でコンパイルできます。

Spring Framework のように log4j ライブラリを参照する API ライブラリを依存関係として使用している場合でも、log4j を参照する依存関係は脆弱なのでしょうか？

それは特定のケース、および log4j ライブラリのどの部分が使用されているかに依存します。log4j-core は脆弱ですが、log4j-api は脆弱ではありません。
最も包括的な結果を得るためには、 JFrog Xray のようなソフトウェア コンポジション アナリシス (SCA) スキャン ツールを使用して、すべてのソフトウェア依存関係における脆弱性を特定することをお勧めします。このスキャンは、当然 log4j に関連するものだけでなく、包括的に脆弱なコンポーネントを検出します。

それが叶わない場合、ソースコードとバイナリで log4j の利用を特定するために、JFrog がコミュニティのために作成した OSS ツールを使用できます（上記を参照）。

Xray が log4shell の脆弱性を持つアーティファクトを検出したら、そのアーティファクトの使用者を特定する方法はありますか？つまりArtifactoryを使用して、どのサービス/ユーザが脆弱なアーティファクトにアクセス/ダウンロードしたかを追跡し、それらの特定のサービスを分析できますか？

もちろんです。JFrog Platform はこのために作られました。Xray と Artifactory を使って、脆弱なアーティファクトの使用者を特定し、次の方法でその使用をコントロールできます。

• log4j パッケージの使用状態についてのリポジトリ検索
• CVE-2021-44228 の検索
• Artifactory で build-info クエリを実行することによる、log4j-core ライブラリに依存するすべてのビルドのリストアップ
• 違反の警告、脆弱なパッケージのダウンロードのブロックをする Xray ポリシーの定義

詳細は、ブログ「Your Log4shell Remediation Cookbook Using the JFrog Platform」をご覧ください。

Xrayによる静的および推移的な依存関係の識別の様子のデモを見ることができますか？

できます。Xrayのデモはこちらからお申込みください。アーティファクトの依存関係のすべてのレイヤーを見通す方法をご紹介します。