マングースCVE-2025-23061およびCVE-2024-53900の技術的発見

Mongoose でスキーマを定義するとき、ref オプションを使ってフィールドが別のモデルを参照するように設定できます。populate() メソッドを使うと、参照先のフィールド(ObjectId)を関連モデルの完全なドキュメントに置き換えることができます。例えば、ブックストアのアプリケーションでは、bookSchemaの author フィールドはAuthorドキュメントを参照し、reviewフィールドはReviewsドキュメントを参照します。populate() メソッドを使用すると、開発者は、ブックモデルへのクエリの際に、authorフィールド (ObjectId) を完全なAuthorドキュメントに置き換えることができます。

populate()を使用すると、ブックモデルへのクエリの際に、著者フィールド(これはObjectIdです)を完全な著者ドキュメントに置き換えることができます：

さらに、Mongoose の populate() メソッドはカスタムクエリをサポートしており、 どの関連ドキュメントをどのように取得するかを定義できます。matchやoptionsといったプロパティを使うと、関連ドキュメントをフィルタしたりソートしたり制限したりスキップしたりできるので、柔軟なデータ取得が可能です。

上の例では match オプションはフィルタオブジェクトで、 MongoDB のクエリオペレータを含めることができます。 詳しくはクエリおよび投影演算子 - MongoDB マニュアル v8.0 を参照ください。注目すべき演算子のひとつが$where で、これは MongoDB サーバ上で JavaScript を直接実行できるようにします。しかし、MongoDB サーバー上での実行には制限があり、 基本的な操作や関数しかサポートしていません。

Dat Phung はpopulate()メソッドのワークフローを理解するために Mongoose のソースコードを徹底的に分析しました。彼は、アプリケーションがモデル上でpopulate()メソッドを呼び出した後、populate() 関数がトリガーされることを突き止めました。この関数の中で Mongoose は _execPopulateQuery() 関数を呼び出し、MongoDB サーバー上で$where演算子を使ったクエリを実行します。その後で、外部コレクションからすべてのドキュメントを取得し、次のステップで展開します。

MongoDB からデータを取得した後、Mongoose はコールバック関数_done() を実行します。この関数は_assign() を呼び出してデータを準備し、assignVals()関数を呼び出して2つのモデルを「結合」します。

この脆弱性は、取得したデータが Mongoose のassignVals() 関数で処理されるときに発生する可能性があります。この関数はmatchオプションが配列かどうかをチェックし、配列の場合は各演算子をsift()関数に渡します。sift() 関数は同じ名前の外部ライブラリからインポートされたもので、 アプリケーションサーバー上でローカルにクエリを処理します。このローカル処理は、特にユーザが制御する入力を処理する場合に、セキュリティ上のリスクをもたらします。

これをさらに調査するために、Dat Phungは条件が満たされるようにmatchオプションの値を変更し、データフローの追加分析のためにsift() 関数を呼び出した。

条件が整ったので、$where演算子をsift()関数に渡しました。

siftライブラリは、配列やJSONオブジェクトなどのデータコレクションをMongoDBライクな構文でフィルタリングしたりクエリしたりするために設計された、軽量のJavaScriptユーティリティだ。公式ドキュメントによると、"Sift は JavaScript で MongoDB クエリを使うための小さなライブラリです" とのことです。sift()関数は、MongoDBライクなフィルター操作をデータベースサーバーではなくアプリケーションサーバー上で評価するため、信頼できない入力を処理する際にシステムを重大なセキュリティリスクにさらす可能性がある。

分析を続けると、フェローは sift ライブラリのcreateDefaultQueryTester()関数の中に問題があることを突き止めました。この関数は match 配列の各オペレーションを実行可能な JavaScript 関数に変換し、それを使って MongoDB ドキュメントデータをローカルでフィルタリングしたり処理したりします。そのためにcreateDefaultQueryTester()はcreateNamedOperation()関数をコールし、 match 配列から$whereなどの操作を引数に渡します。 

createNamedOperationは、マッチ配列の各オペレーションについて、そのオペレーションがサポートされているかどうかをチェックし、対応する関数に渡す。

操作が$whereの場合、生の "params "値を使ってJavaScript関数が生成されます。この関数は、マッチ配列の$where演算子から派生したもので、ユーザーが制御することができます。

当初、クエリーは別のプロセスの実行に失敗し、次のようなエラーが発生した：

このエラーは、Mongoose が sift() 関数に制御を渡す前に MongoDB サーバーで$where演算を実行しようとしたことを示しています。しかし MongoDB の$where句では JavaScript 関数に制限があるため、エラーが発生してクエリが実行できません。その結果、Mongoose はsift() 関数に到達する前に処理を止めてしまいます。

この制限を回避するために、フェローはアプリケーションサーバーに存在する "global "変数を利用した。この方法によって、彼はMongoDBサーバーの制限を回避し、クエリがsift()関数に到達できるようにした：

この値では、Mongoose が MongoDB で$where演算を実行するときに、"global" 変数がないと三項演算子(typeof global != "undefined" ? global.process.mainModule.constructor._load("child_process").exec("calc") ：1)で 1 を返し、MongoDB がエラーを投げるのを防ぎます。その結果、MongoDB サーバーでクエリが問題なく実行されます。

しかし、同じ値が、"global "変数が利用可能なアプリケーション・サーバー上で実行されるsift()関数に到達すると、以下の関数が作成されるトリガーとなる：

このビデオは、8.8.3より前のバージョンのMongooseに影響するCVE-2024-53900のProof of Conceptを示しており、siftライブラリと一緒に$where演算子の悪用を防ぐための適切な入力検証が欠けています。

このスニペットは、 populate() に渡された match プロパティが配列であるかどうかをチェックします。もしそうなら、コードは配列の各オブジェクトを繰り返し、 $where演算子を含むかどうかを調べます。もし$where が検出されるとエラーが発生し、悪意のあるペイロードが危険な sift() 関数に伝搬するのを防ぎます。  

その結果、CVE-2024-53900を悪用するペイロードは、マッチ配列のオブジェクトが$whereを含むため、このチェックに失敗し、事実上sift()に到達できない。

このアップデートでは、1つの入れ子レベル内での$where の直接の使用は正しくブロックされますが、 $or演算子 (MongoDB と sift ライブラリの両方が完全にサポートしている構造) の中に埋め込まれた$where は 検出されません。

その結果、攻撃者は$or の下に$where を入れ子にして、パッチのシングルレベルチェックを逃れることができます。Mongoose はマッチ配列の各オブジェクトのトップレベルのプロパティだけを検査するので、 バイパスペイロードは検出されずに残り、最終的に sift ライブラリに到達し、 悪意のある RCE を可能にします。

さらに、CVEs は次のものによっても検出できます。 MetaDefender Software Supply Chainによって検出することもできます。