ハクソク

世界を動かす技術を、日本語で。

MongoBleedを簡単に解説

148日前原文(bigdata.2minutestreaming.com)

概要

  • MongoBleed（CVE-2025-14847） は2017年以降のほぼ全てのMongoDBバージョンに影響する深刻な脆弱性
  • zlib圧縮処理のバグ により、攻撃者が認証なしでヒープメモリの未初期化データを読み取れる
  • パッチ済みバージョンあり だが、EOLバージョン（3.6/4.0/4.2）は未対応
  • インターネット公開MongoDB が21万台以上確認され、広範囲なリスク
  • 対策はアップデートまたはzlib圧縮無効化 が推奨

MongoBleed（CVE-2025-14847）の概要

  • MongoBleed はMongoDBの zlib圧縮経路 に存在する重大バグ
  • 攻撃者は 認証不要 でデータベースへ接続し、脆弱性を突くことが可能
  • 未初期化ヒープメモリ の内容（パスワード、APIキー、顧客データ等）を取得可能
  • 2017年5月 のPRでバグが導入され、 2025年12月 に修正
  • EOL（サポート終了）バージョンでは パッチ提供なし

技術的な詳細

  • MongoDB独自のTCPプロトコル と BSONフォーマット を利用

  • 通信は OP_MSG コマンドのみで行われる設計

  • 圧縮通信時 はOP_COMPRESSEDメッセージを使用し、ヘッダ内の uncompressedSize （復元後サイズ）を信頼してバッファを確保

  • 実際のデータより大きなuncompressedSizeを指定すると、 余分なヒープメモリ がバッファに含まれる

    • 例：[1KBの実データ | 999KBのヒープガーベジ]

  • バグにより 実際の復元サイズを確認せず、ユーザー入力値をそのまま利用

  • C++実装 のため、バッファには過去の処理で使われた 機密情報 が残留

攻撃手法の流れ

  • 攻撃者は 不正なzlib圧縮リクエスト を送信

  • BSONの最初のフィールド（C言語のnull終端文字列）をパース時、 null終端が無い 不正BSONを送り込む

  • サーバは バッファ内のヒープガーベジ までスキャンし、最初のnullバイトまでをフィールド名として認識

  • エラーレスポンスに 無効なフィールド名 を含めて返却 → 攻撃者は 漏洩データ を取得可能

    • 例：{ "ok": 0, "errmsg": "invalid BSON field name 'a | password: 123'", ... }

  • 攻撃者はこれを 自動化・多量実行 し、ヒープ全体を探索可能

影響範囲・リスク

  • 認証前処理 で発生するため、 公開DBは即危険
  • Shodan によると、 21万台以上 のMongoDBがインターネット上で公開状態
  • ユーザー情報、パスワード、APIキー、設定情報、顧客データ等 あらゆる機密情報 が漏洩するリスク

対策・緩和策

  • MongoDB最新版へアップデート （8.0.17以降等）を推奨
  • zlibネットワーク圧縮の無効化 も有効な暫定策
  • EOLバージョン は修正対象外のため、 早急な移行 が必要

タイムライン

  • 2017年6月1日 ：バグを含むコミットがマージ
  • 2025年12月17日 ：修正コード作成
  • 2025年12月19日 ：CVE公開、Atlasクラウドパッチ適用
  • 2025年12月22日 ：パブリックリポジトリに修正マージ
  • 2025年12月24日 ：公式パッチアナウンス、「Atlas全DBパッチ済み」発表

参考情報・検知ツール

  • 公式CVE情報 https://nvd.nist.gov/vuln/detail/CVE-2025-14847
  • バグ導入PR https://github.com/mongodb/mongo/pull/1152
  • 修正コミット https://github.com/mongodb/mongo/commit/505b660a14698bd2b5233bd94da3917b585c5728#diff-e5f6e2daef81ce1c3c4e9f7d992bd6ff9946b3b4d98a601e4d9573e5ef0cb07dR77
  • 攻撃検知・解説記事 https://www.ox.security/blog/attackers-could-exploit-zlib-to-exfiltrate-data-cve-2025-14847/ https://blog.ecapuano.com/p/hunting-mongobleed-cve-2025-14847
  • PoC・検知ツール https://github.com/joe-desimone/mongobleed https://github.com/Neo23x0/mongobleed-detector

総括

  • MongoBleedはHeartbleed級のデータ漏洩バグ
  • 認証前に発生し、攻撃が極めて容易
  • インターネット公開DBは即時対策必須
  • パッチ適用またはzlib圧縮無効化が最優先
  • EOLバージョン利用者は早急な移行・閉鎖推奨

Hackerたちの意見

Mongoのインスタンスがどれくらいの頻度でインターネットにさらされてるんだろう？自分はSQL派なんだけど、知ってる限りではあんまりないけど、たまにはあるよね。

└

記事には、213Kの露出したインスタンスを報告しているshodanのスキャンがリンクされてるよ。 https://www.shodan.io/search?query=Product%3A%22MongoDB%22

└

Mongoを使う理由の一つとして、スキーマを考えたくないっていうのがよく挙げられるよね。（自分が知ってる「真剣な」組織3つ中3つがそうだった）今やるべきことを後回しにして、後で頭を悩ませたくないっていう傾向が、「内部ネットワークを構築する手間を省くためにDBを公開しちゃおう」っていうのと重なってる気がする。

└

自分の経験から言うと、MongoDBの存在理由は「怠惰」そのものだよ。* スキーマを気にしなくていい。* 永続性や耐久性を気にしなくていい。* 読み書きを気にしなくていい。* 接続性を気にしなくていい。これが基本的な哲学だから、ユーザーが基本的なセキュリティを気にしないのも全然驚くことじゃないよね。

└

長い間、デフォルトインストールではすべてのインターフェースにバインドされていて、認証が無効になってたんだよね。

└

よくあることだよ。これが原因でデータ漏洩がたくさん起きてる。人々はクラウドのVMを立ち上げて、パブリックIPが常にあることを忘れちゃうんだよね。

└

SQLサーバーを公開したままにしておくと、たいていもっと悪いことになるからかもね。例えば、追加の設定をしないと、PostgreSQLはホストマシン全体を支配できる設定になる。システムプロセス管理を可能にするような、デフォルトで無効になっていない obscure な機能があるかもしれない。結果的に「みんな」が知ってるのは、パスワードなし、もしくは弱い/デフォルトのパスワードでPostgreSQLインスタンスを公開すると、数分でハッキングされるってこと。攻撃者は怠け者だから、クリプトマイニングのマルウェアを走らせるだけだしね。

└

みんな、この意見真剣に言ってるの？ スケールでNoSQLとSQLの両方を使うことはよくあるよ。NoSQLはデータの高可用性のために使われるんだ。iMessageはメッセージスレッドに、EAはゲームのマッチメイキングに使ってることで有名だよ。要するに、SQLとNoSQLの両方を持つべきなんだ。NoSQLは高可用性のためのリソースキャッシュみたいなもの。ソーシャルメディアアプリを作ると想像してみて…もちろん、すべてのデータを保存するためのSQLデータベースはあるけど、投稿のAPIキャッシュをNoSQLで維持してるよ。なんで？ それは、他の黒か白かの侮辱にも関係してるけど、NoSQLは通常SQLよりもずっと速いからだよ。だから使うんだ。ハードドライブからJSONファイルを読む方が、SQLデータベースをクエリするよりもずっと速い。じゃあ、なんでNoSQLをすべてに使わないの？ それは、関係性がないからどこにでもデータが重複してしまうし、基本的には巨大なキャッシュだからだよ。ドキュメントが巨大になると、クエリも遅くなるしね。とにかく、両方必要なんだ。どちらか一方だけではないよ。こんなに年が経っても、SQLとNoSQLの目的を知らない人がいるなんて信じられないし、全然競争じゃないことも理解してないんだね。両方欲しいんだよ！

└

私の大学にはインターネットにさらされているサーバーがあって、まだパッチが当てられてない。みんな休暇中で、誰に連絡すればいいのか全く分からない。

OWASPのトップ10がもたらす仮想的な楽観主義について考え続けてる。重大な欠陥が解決されることを願ってるけど、バッファオーバーフローは2003年からずっとあるんだよね。

└

みんなに足元をすくう武器を渡してるようなもんだから、これは永遠に避けられないと思うよ。Mongoの開発者たちに思いを馳せるよ、私たちがこのエラーを防ぐ言語に移行するまで。

数年前、Cloudflare Workersのランタイムで使われているメモリアロケータをパッチして、解放時にすべてのメモリを静的なバイトパターンで上書きするようにしたんだ。そうすれば、初期化されていないアロケーションには何も面白いものが含まれないからね。これがパフォーマンスに悪影響を与えると思ってたけど、実際には影響を測ることができなかった。メモリ安全でない言語でまだ働いてる人は、これをやった方がいいと思う。これでMongoのバグも軽減できたはず。

└

そういえば、そんなこと考えたこともなかったけど、確かに理にかなってるね。その静的バイトパターンによるオーバーヘッドは、ガベージコレクターみたいなものに比べたら、ほとんど微々たるものだろうし。

└

参考までに、少なくともC/C++では、コンパイラはポインタがfree()に渡される直前に、そのポインタが指すメモリへの代入を捨てることができるから、やり方によってはパフォーマンスに影響がないこともあるよ。コンパイラが代入を削除したからかもしれない。これ、memset()の呼び出しにも影響するから、ここを見てみて: https://godbolt.org/z/rMa8MbYox

└

数年前、Cloudflare Workersのランタイムで使われているメモリアロケータをパッチして、解放時にすべてのメモリを静的なバイトパターンで上書きするようにしたんだ。これで初期化されていないアロケーションには面白いものが含まれないようにね。多くのmalloc実装は、適切な環境があればこれを自動でやってくれるよ。例えば、FreeBSDでMALLOC_CONFをopt.junk=freeに設定すれば、これが実現できる。

└

OpenBSDでは、新しく割り当てられたメモリには0xdbを、解放されたメモリには0xdfを使って埋めるんだ。これによって、開発者は「初期化前の使用」（0xdbを見る）や「解放後の使用」（0xdfを見る）バグをすぐに見つけられるんだって。どうやら、これはOpenBSDのデフォルトみたいだね。

└

最近のmacOSバージョンでは、メモリを解放するときにゼロクリアするから、メモリ圧縮の効果が上がるんだって。どうやら、平均的にはパフォーマンスが向上するみたい。

著者は、Mongoが内部でプライベートリポジトリで開発されていて、コミットが後に公開リポジトリに公開されることを知らないみたい。これが日付に関する混乱の原因なんだよ。

└

確かに知らなかった。PRの「Mongoの公開レビューのやり方は知らない」っていうゼロレビューについて話してるとき、こういうことがあるかもって疑ってたんだ。でも、これを知れてよかった。今、これを言及して、日付の不一致について説明するために更新してるところ。

この投稿の作者はタイムラインについて間違ってるよ。私たちのAtlasクラスターは、CVEが発表される数日前にアップグレードされたんだ。

└

ありがとう！更新したよ。

なんで誰もがMongoを使ってるの？

└

これは許せない、ひどい広告のような議論だ。

└

それは「ウェブスケール」だからだよ。 ref: https://www.youtube.com/watch?v=b2F-DItXtZs

└

簡単にレプリケーションできるね。PostgresのJSONBよりも速いと思う。使いたくはないけど、MongoDBやDynamoDBが技術的に適切な選択になる場合もあるのは分かる。

└

そうだよね？出たときはNoSQLがすごく注目されてたけど、結局はキー・バリュー型データベースのことだけだったんだよね、たくさんあるし。

12月24日、MongoDBは誰かがCVEを悪用した証拠はないと報告した。「証拠がないことは、存在しない証拠ではない…」

└

彼らに何を言ってほしいの？

誰かがNoSQLについて投稿するたびに、千人の「プログラマー」がたくさんのトラフィックをサポートしたことがないことがバレるね（笑）

本当にUbisoftがハッキングされて、900GBのデータが漏れたって話、モンゴーブリードのせいなの？今日、#ubisoftのタグでSNSにたくさん投稿が上がってるのを見たんだけど。HNの誰か確認してくれない？

└

TLDR: NoSQLじゃなくてログを責めろ。メールや支払い情報が漏れたって話を聞くとき（Twitterがパスワードを平文で保存してた時も笑）ほとんどがログからなんだ。多くの場合、ログはNoSQLに保存されてることが多いけど、それはJSON形式で必要なだけで、すごく高い可用性が求められるから（Herokuユーザーたち、ずっとログを追ってるの、ありがとね）それで、電話番号やメールアドレスがログに入るときはほとんど誰も暗号化しないんだ。実際、ログにはほとんどセキュリティがない。バックエンドデータのスナップショットみたいなもので、誰も気にしないんだよね。とにかく、NoSQLを使う選択とは関係ないし、むしろその周りのセキュリティがどれだけ無視されているかが問題だと思う。ちなみに、Twitterの平文パスワードの件と、君が言ってたRainbow Six Siegeのデータ漏洩も、どちらもログから漏れたんだよ。NoSQLのログだけど、ログの周りのデータセキュリティが重要だと思う。

└

Ubisoftのサポートスタッフが賄賂を受け取っていたから、ハッキングが可能になったって聞いたよ。