MongoDB 圧縮リーク ラボ (安全、教育用)

参考 CVE : CVE-2025-14847

このリポジトリは、データベースワイヤプロトコルにおける「圧縮フレーミング / サイズメタデータのメモリ開示」として説明される問題のクラスの 概念 を実証する 教育用ラボ です。

これは防御的な理解を支援するために書かれています: MongoDB のネットワーク圧縮がどのようにネゴシエーションおよびフレーミングされるか、なぜ サイズフィールド が重要なのか、そして堅牢なパーサーがどのように意図しないメモリ露出を防ぐのか。

CVE 参照に関する注意: このラボは CVE-2025-14847 として参照されるアイデアを中心に構成されています。このリポジトリは、特定のベンダーのバグを検証、再現、悪用したり、特定の MongoDB バージョンが影響を受けると主張したりするものでは ありません。これは一般的な障害モード (圧縮ペイロード周辺のサイズメタデータの不一致) と緩和策に焦点を当てています。

バージョンステータス (脆弱 vs パッチ適用済み)

このリポジトリには、特定の CVE に対して脆弱またはパッチが適用されている MongoDB バージョンの証拠は 含まれておらず (また使用すべきではありません)。

レポートのために「脆弱」と「パッチ適用済み」のバージョンを正しく文書化するには、その CVE に関する 公式のベンダーアドバイザリ / リリースノート を使用し、それを引用してください。

実行中のものを確認するための実用的な手順:

• Docker コンテナのバージョン:
  • docker compose exec mongodb mongod --version
  • または docker compose exec mongodb mongosh --quiet --eval "db.version()"
• ホストインストールのバージョン:
  • mongod --version
  • mongosh --quiet --eval "db.version()"

使用しているアドバイザリのリンクを共有していただければ、推測せずに README に「影響を受ける / 修正済み」の表をきれいにフォーマットできます。

脆弱性とは何か (概念的に)

このラボは 圧縮フレーミング / サイズメタデータの不一致 障害モードを示しています:

• MongoDB メッセージは長さプレフィックス付きです。ネットワーク圧縮を使用する場合、OP_COMPRESSED エンベロープにより さらに多くの サイズフィールド (外部メッセージ長、宣言された非圧縮サイズ、内部メッセージ自身の長さ) が追加されます。
• 実装がこれらのサイズフィールドのいずれかを厳密な検証なしに 信頼 する場合、デコンプレッションまたはパース中にバッファを誤って処理する可能性があります。
• バグのある実装では、これにより 範囲外読み取り や 初期化されていないバッファバイト の返却につながる可能性があり、これが「メモリ開示」が発生する一つの方法です。

詳細なフレーミングの説明については protocol_overview.md を参照してください。

倫理的免責事項

• このプロジェクトは 設計上悪用不可能 です。
• 武器化されたロジック、エクスプロイトコード、またはシステムを侵害するための技術は 含まれていません。
• ここで提供される ローカル Docker コンテナ に対してのみ実行してください。
• このコードを、自分が所有していない、またはテストする明示的な許可がないシステムに向けて使用しないでください。

学習目標

このラボの終了時には、以下ができるようになるはずです:

• MongoDB の ワイヤプロトコルフレーミング がどのように機能するかを高レベルで説明できる。
• zlib ネットワーク圧縮 がどのようにネゴシエーションおよび適用されるかを説明できる。
• 不正な長さ / サイズメタデータ が、バグのある実装において 概念的に メモリ露出につながる可能性がある方法を理解できる。
• 実用的な緩和策 (パッチ適用、構成強化、ネットワーク検出) を特定できる。

このリポジトリが行うこと (および行わないこと)

行うこと:

• zlib 圧縮を有効にした MongoDB を Docker で起動する。
• 小さなオリジナルの Python クライアントを使用して以下を行う:
  • compression: ["zlib"] を含む非圧縮の hello を送信する
  • zlib を使用する 正しくフレーミングされた OP_COMPRESSED メッセージを送信する
  • 非圧縮 vs 圧縮サイズ とサーバー応答の概要をログに記録する
• 防御的なパーサーがどのように一致しないサイズメタデータを拒否するかを示すローカルの「おもちゃパーサー」デモを含む。

行わないこと:

• 実際の悪用のための悪意のあるパケットを作成しない。
• 認証バイパスを試みない。
• 任意のメモリの読み取りを試みない。

リポジトリの内容

• docker-compose.yml – zlib 圧縮を有効にし、localhost のみ に公開された MongoDB コンテナを実行する。
• protocol_overview.md – ワイヤプロトコル + BSON + 圧縮ワークフロー + 概念的な脆弱性の説明。
• mitigation.md – 防御ガイダンス: パッチ適用、設定、および検出のアイデア。
• lab_probe.py – 圧縮をネゴシエートし、メッセージサイズを安全にログに記録するオリジナルのプローブ。

ラボを安全に実行する方法

1) 前提条件

• Docker Desktop (または互換性のある Docker エンジン)
• Python 3.10+ (推奨)

2) MongoDB を起動する

このリポジトリのディレクトリから:

docker compose up -d

実行中であることを確認:

docker compose ps

3) プローブを実行する

python .\lab_probe.py

期待される出力:

• 最初の hello からネゴシエートされた圧縮方式を表示
• リクエスト/レスポンスサイズを表示
• 圧縮された hello を送信し、圧縮および解凍されたメッセージサイズの両方をログに記録

4) おもちゃデモを実行する (ネットワークなし)

python .\lab_probe.py --toy-demo

これはローカルのパースチェックのみを実行し、サイズ検証 がなぜ重要かを示します。

5) シャットダウン

docker compose down

安全上の注意

• コンテナはホスト上で 127.0.0.1:27017 にバインドされています。
• エクスプロイト動作は存在しません。
• プローブは保守的な制限 (例: 最大メッセージサイズ) を実施し、すべての長さフィールドを検証します。