Windowsサンドボックス化の暗部:Brokering File Systemの脆弱性

Image

Microsoftは約2年前にWin32 App Isolationを導入しました。これは、Windowsクライアントシステム上でアプリケーションの分離を強化するために設計された仕組みです。並行してBrokering File System (BFS)もリリースされました。これは、分離環境で実行されるアプリケーションによるファイルシステム、パイプ、レジストリへのアクセスを仲介する役割を担うドライバであり、セキュリティの観点から潜在的に興味深いコンポーネントとなっています。

この文脈で位置づけられるのがCVE-2025-29970です。これはbfs.sysドライバで見つかったuse-after-free型の脆弱性で、当初HT3Labsによって発見されました。技術分析はドライバの26100.4061版に対して行われ、BFS内部構造に関連するメモリ管理の誤りに関するものです。

BFSはAppContainerとともに、そして後にAppSiloとともに登場し、分離コンテキストから発生するI/O操作を制御することを目的としています。そのために、ユーザー、アプリケーション、パスに基づくアクセス・ポリシーを適用できる一連のデータ構造を用い、同時に良好な性能も確保しています。

この仕組みの中心にあるのがPolicyTableで、個々のPolicyEntryをハッシュテーブルに格納します。各PolicyEntryはアクセスルールを表し、ユーザーのSID、AppContainerのSID、StorageObjectへの参照に加え、ライフサイクル管理に用いられる参照カウンタなどの情報を含みます。

StorageObjectにはポリシーで制御されるパスに関する詳細が含まれており、複数の内部構造を使用します。その中にはDirectoryBlockListがあり、これはポリシーに関連付けられたファイルやサブディレクトリを表す連結リストです。このリストはルートディレクトリが開かれたときに割り当てられ、時間の経過とともに1つ以上のエントリで埋められていきます。

脆弱性 CVE-2025-29970は、ポリシー削除の段階、特にBfsCloseStorage関数において顕在化します。DirectoryBlockListの解放中に、要素を走査するループ内でリストの先頭が解放されてしまい、リストに複数のエントリが含まれる場合に、すでに解放されたメモリのデリファレンスが発生します。

Microsoftは、解放ロジックを分離することでこの問題を修正しました。BfsCloseRootDirectory関数の導入により、連結リストの先頭を解放する前にすべての要素が解放されるようになり、根本原因であるuse-after-free条件が解消されました。

悪用の観点では、この脆弱性が提供する余地は限定的です。関与するポインタは任意の読み取りや書き込みを可能にするものではなく、メモリ解放から再利用までの時間窓も極めて短いからです。それでも本件は、サンドボックス化に関連するドライバが依然として重要な攻撃面であること、特にWindowsにおける分離機能の拡大に伴いその傾向が強まることを示しています。

翻訳元: https://www.redhotcyber.com/post/il-lato-oscuro-del-sandboxing-windows-vulnerabilita-nel-brokering-file-system/

ソース: redhotcyber.com