compress-lzf に範囲外メモリ読み出し、1.2.0で修正
Javaの圧縮ライブラリ Ning compress-lzf の1.2.0より前の版に、細工されたLZFデータを処理させるとJVMのメモリ内容が漏れたり、JVMが停止したりする脆弱性(CVE-2026-109395)が見つかりました。外部から受け取ったLZFデータを展開するJavaアプリケーションが影響を受けるため、利用の有無を確認し、1.2.0以降への更新を進めてください。
急ぎ度: 早めに
CVSS 9.1の重大な脆弱性で、認証なしにネットワーク経由で悪用できますが、実際の攻撃での悪用が確認されたという公表は現時点でなく、影響は外部データを展開するアプリケーションに限られるためです。
関係があるか
Javaアプリケーションが Ning compress-lzf を使い、外部から受け取ったLZF形式のデータを既定のデコーダーで展開している環境が対象です。自社開発のシステムのほか、ライブラリを内部に同梱している他社製品やミドルウェアも該当しうるため、直接の依存関係だけでなく間接的な依存も確認が必要です。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| Ning compress-lzf | 1.2.0より前のすべての版 | 1.2.0 |
確かめ方
- 1Maven、Gradleなどのビルド定義と依存関係の一覧で、
compress-lzfが含まれていないか確認します。他のライブラリ経由で取り込まれる間接的な依存も見てください。 - 2本番環境にある実行ファイル(JAR、WAR)の中身を調べ、
compress-lzfのJARやcom/ning/compress/lzfのクラスが含まれていないか確認します。依存を1つのJARにまとめた形式でも見つかります。 - 3該当した場合は、そのアプリケーションが外部(ネットワーク越しの通信、利用者のアップロード、外部システムとの連携データなど)からLZF形式のデータを受け取って展開していないか、開発担当者に確認します。
- 4他社製品に同梱されている可能性がある場合は、ベンダーの告知や部品表(SBOM)で、該当ライブラリの版を確認してください。
何が起きたか
Ning compress-lzf は、LZFという形式でデータを圧縮・展開するJava向けのライブラリです。1.2.0より前の版には、展開処理の途中で本来読んではいけないメモリの領域を読んでしまう弱点があります。細工された圧縮データを渡されると、展開結果に関係のないメモリの内容が混ざって出力されたり、JVM(Javaの実行環境)ごと停止したりする恐れがあります。
技術的には、sun.misc.Unsafe を使う高速な UnsafeChunkDecoder が、圧縮データ内の「後方参照」と「リテラルの連続部分」が指す範囲を十分に検証していません。そのため、データが示す範囲がバッファの外にはみ出しても処理が進んでしまいます。既定の LZFDecoder を使っているアプリケーションが対象です。
分類はCWE-125(領域外読み取り)で、深刻度はCVSS v3.1で9.1(Critical)です。修正は1.2.0で行われており、修正内容は公開されているコミットとプルリクエストで確認できます。
攻撃の流れ
-
1
細工データ作成
攻撃者が、範囲の指定が不正なLZF形式のデータを用意します。
-
2
アプリに送信
LZFデータを受け付けるアプリケーションへ、ネットワーク経由で送ります。
-
3
展開時に範囲外参照
既定のデコーダーが範囲を確認しないまま処理し、メモリの外側を読みます。
-
4
漏えいまたは停止
展開結果に別のメモリ内容が混ざって出力されるか、JVMが異常終了します。
どう悪用されるか
悪用に認証や利用者の操作は必要ありません。攻撃条件の複雑さは低いとされ、ネットワーク経由で成立します。ただし、攻撃者が細工したLZFデータをアプリケーションに渡せることが前提です。LZFデータを外部から受け取らない使い方であれば、攻撃者が入力を差し込む余地は小さくなります。
被害は2つ考えられます。1つは機密性への影響で、展開結果にJVMのヒープ上の無関係なデータが混ざり、その内容が呼び出し元や利用者に返る可能性があります。どんな情報が含まれるかはアプリケーションの状態によって変わります。もう1つは可用性への影響で、JVMが停止すると、同じJVM上で動くサービス全体が止まります。データの改ざん(完全性)への影響はないとされています。
今すぐやること
-
1
利用箇所を洗い出す
自社のJavaアプリケーションと、他社製品に同梱されたものの両方で、compress-lzf を使っていないか確認します。間接的な依存も対象に含めてください。
mvn dependency:tree -Dincludes=com.ning:compress-lzf -
2
外部入力を扱う箇所を優先する
インターネットや外部システムから受け取ったLZFデータを展開しているアプリケーションを、更新の最優先にします。社内の信頼できるデータだけを扱う箇所は、その次の順番で構いません。
-
3
1.2.0以降へ更新する
依存する compress-lzf の版を1.2.0以降に上げ、再ビルドして再配備します。間接的な依存の場合は、依存関係の管理機能で版を固定するか、上位のライブラリの更新を待ちます。
gradle dependencies --configuration runtimeClasspath -
4
同梱製品はベンダーに確認する
自社で更新できない製品に含まれている場合は、ベンダーの告知で対応版の提供状況を確認し、適用の時期を決めます。
-
5
更新後に動作を確認する
更新後は、既存のLZFデータの展開が正常に動くことと、異常な入力でJVMが停止しないことを、テスト環境で確認します。
すぐ更新できないとき
すぐに更新できない場合は、信頼できない送信元からのLZFデータをアプリケーションに渡さないよう、入口で制限します。LZF形式を受け付ける機能やエンドポイントを一時的に止めるか、認証済みの限られた相手だけに絞ることも有効です。Unsafeを使わないデコーダーに切り替えられるかどうかは、アプリケーションの実装やライブラリの仕様によって異なるため、開発担当者が公式の情報で確認してください。
背景
圧縮ライブラリは、通信データ、キャッシュ、ログ、メッセージ基盤などの内部で目立たずに使われ、依存関係をたどって初めて存在に気づくことが少なくありません。利用者の入力を直接解釈する部品であるため、弱点があれば外部からの攻撃の入口になりやすい種類のソフトウェアです。
展開処理でデータが示す長さや位置を十分に確認しないために、範囲外のメモリを読んだり書いたりする問題は、圧縮・展開に限らずデータ形式を解析するライブラリで繰り返し見つかってきた典型的な弱点です。今回は、Javaの通常の安全機構を迂回して高速化する sun.misc.Unsafe を使った実装で、その検証が不足していました。
よくある質問
Q.自社のアプリで使っているかどうか分からない場合は?
compress-lzf が含まれていないか確認してください。他のライブラリ経由の間接的な依存や、JARに同梱された形での利用もあるため、依存関係のツリーと実行ファイルの中身の両方を見るのが確実です。Q.compress-lzf を使っていれば、必ず攻撃されますか?
Q.実際に攻撃は起きていますか?
Q.どの版に上げればよいですか?
まだ分かっていないこと
- compress-lzf を同梱している具体的な製品名や、それらの製品の対応状況は公表されていません。各ベンダーの告知を確認する必要があります。
- 実際の攻撃で悪用されたかどうかは、現時点で明らかになっていません。
- メモリの漏えいで、実際にどのような情報が外部に出うるかは環境によって異なり、一般的な範囲は示されていません。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Ning compress-lzf before 1.2.0 contains an out-of-bounds memory access vulnerability in the sun.misc.Unsafe based UnsafeChunkDecoder that fails to validate back-references and literal runs. Attackers can supply crafted LZF streams to applications using the default LZFDecoder to leak unrelated JVM heap memory into decompressed output or crash the JVM.
出典: NIST National Vulnerability Database NVD GitHub Advisory
参照URL
- web github.com
- web github.com
- web github.com
- web github.com
- web github.com
- web vulncheck.com
- web nvd.nist.gov
- web github.com