Log4j 脆弱性アラート：Maven Central に脆弱な数百パッケージが存在
人気の高い Apache Log4j ライブラリに新たに発見された脆弱性（CVE-2021-44228（別名：Log4Shell）およびCVE-2021-45046）に関連するリスクの高さから、通常とは異なる規模と緊急性のセキュリティ騒動が発生しています。開発者やセキュリティチームは、Log4j の脆弱性が自社のソフトウェアに与える影響を調査するよう迫られ、その過程で複数の技術的課題が明らかになりました。
Log4Shell が公表されて以来、JFrog セキュリティ・リサーチ・チームは、開発者コミュニティが新しい脅威にできるだけ迅速かつ効率的に対処できるようにすることに着手しました。この問題を分析した結果、コードに含まれる可能性のある Log4j を検出するためにプロジェクトの依存関係を使用することは有益であるものの、使用されている Log4j コードのすべてのインスタンスを検出するわけではないことが判明しました。つまり、依存関係のスキャンだけに頼っていると、脆弱なアプリケーションが気づかれないままになる可能性があります。より完全な検出機能を提供するために、私たちは、ソースコードとバイナリの両方から Apache Log4j の存在とその利用を検知するように設計された独自の Log4j 脆弱性スキャンツールをリリースしました。
先日のブログ「JFrog OSS スキャンツールによる Log4j 検出」では、パッケージの依存関係を超えてスキャンすることで、Log4j の脆弱性検出を改善するために実施したアプローチについて説明しました。以下は、JFrog の新しい OSS ツールを使用して、Maven Central リポジトリの Java パッケージをスキャンした際に得られた新しい発見です。
Log4Shell を徹底的にスキャンすることの重要性
Log4Shell にさらされているかどうかをチェックする明白な（しかし不完全な！）方法は、脆弱なバージョンの Log4j がビルド構成（`pom.xml`、`gradle.build`など）でプロジェクトの依存関係としてリストされているかどうかを見ることです。より正確ですが、より時間のかかるアプローチは、Log4j が間接的な依存関係として含まれているかどうかをチェックすることです（`gradle -q dependencies` または `mvn dependency:tree`）。驚くべきことに、この方法も不完全で、最終製品に脆弱な Log4j コードが含まれていないことを確認するためには、より深い調査が必要です。
完全な依存関係リストをスキャンするという方法では、含まれている Log4j コードのインスタンスを見逃してしまうことがある理由は、依存関係は単にその対象アーティファクトを構築または実行するために必要な外部パッケージを指定しているにすぎないからです。脆弱なコードがコードベースに直接挿入されている場合、それは依存関係ではありません。したがって、脆弱な Log4j コードをより正確に検出するためには、コード自体を検査する必要があります。
パッケージへの Log4j の混入 ー Maven Central での調査結果
かつての調査では、Maven Central リポジトリの約 17,000 の Java パッケージに、脆弱な log4j-core ライブラリが直接または間接的な依存関係として含まれていることが判明しています。JFrog の調査では、依存関係のスキャンでは検出されない、Log4j の脆弱性を含むパッケージをさらに特定することに重点を置きました。つまり、アーティファクト自体に脆弱な Log4j のコードを含むパッケージです。
Maven Central でパッケージの最新バージョンを調査し、その数をある程度把握しました。全体として、アーティファクトに Log4j コードを直接含めることは、依存関係を介した Log4j の使用ほど一般的ではありません。しかし、Log4j コードを直接含むパッケージは数百（~400）に上り、これらのパッケージは Log4j の脆弱性にさらされます。すべてのケースの半分以上（~65%）で Log4j コードはクラスとして直接含まれています（ダイレクトインクルージョン / シェーディング）。それ以外では典型的に、完全な Log4j .jar ファイル（いわゆる fat jar）を含みます。これらの数字は、完全な .jar ファイルのみを検索するツールでは Log4j が直接含まれているケースのほとんどを見逃してしまうことを示しています。
調査結果のもう１つの興味深い指標は、Log4j がアーティファクトに含まれるだけでなく、間接的な依存関係としても含まれるケースの数です。このケースでは2つのコードに直接的なリンクはありません。コードの包含は、1つのバンドルされたライブラリの要件から生じるかもしれませんし、外部依存として Log4j を必要とするかもしれません。JFrog の調査では、Log4j コードが完全な .jar ファイルではなくクラスとしてアーティファクトに直接含まれているケースの約 30 ％が、アーティファクトの依存関係リストに表れません。これらのケースは、依存関係ツリーでのライブラリ名の明示的な言及、または完全な .jar ファイルの含有を探すツールによって発見されません。
推奨
JFrog セキュリティ・リサーチ・チームは、すべての開発者が細心の注意を払い、自社のソフトウェア製品が、自社が開発したファーストパーティ・コードとアプリケーションで使用されているサードパーティ・コードの両方で、パッチが適用されていないバージョンの Log4j2 を使用していないかどうかを注意深くチェックすることを推奨しています。
自動化されたディープスキャンツールを使用して、リリースされた成果物に Log4j を含める可能性のあるすべての方法がカバーされていることを確認しながら、Log4j の脆弱性の検出を加速し、簡素化することをお勧めします。
Log4j の脆弱性とその影響について、さらに詳しい内容を発信しています。
JFrog セキュリティ・リサーチ・チームの以下のリソースをご覧ください。
Log4Shell ゼロデイ：知っておくべきこと – ブログ
Log4j Log4Shell Vulnerability Explained – ウェビナー
Log4j Log4Shell 脆弱性に関するQ&A – ブログ
JFrog OSS スキャンツールによる Log4j 検出 – ブログ
