CVE-2026-83991: 呼び出し元が削除できないファイルを上書きする

これらの行を隣り合わせに置いたのは、分けてしまうとバグが実際よりも複雑に見えてしまうからだ:

CreateFileW, GENERIC_WRITE             error 5
DeleteFileW                            error 5
CfCreatePlaceholders, SUPERSEDE        S_OK
per-entry Result                       S_OK

書き込みオープン、削除の試行、Cloud Files の呼び出しは、同じパス名と同じスレッドトークンを使用している。最後の呼び出しの前、その名前は保護された DACL を持ち、reparse point ではない通常のファイルに属していた。呼び出しの後、FSCTL_GET_REPARSE_POINT は IO_REPARSE_TAG_CLOUD を返す。

Microsoft はこの結果を CVE-2026-83991、Windows Cloud Files Mini Filter Driver の改ざんの脆弱性として公開した。私は報告書ではこれを不適切な認可と表現し、CWE-863 を提案していた。Microsoft は代わりに CWE-306 を割り当てた。

このプログラムは、テストディレクトリ、ファイル、DACL、または sync root を作成する前に、制限付きの偽装トークンをインストールする。興味深い呼び出しのためだけに、昇格したセットアップの後にトークンを切り替えるようなことはない。アカウントが Administrators SID を持っている場合、CreateRestrictedToken はそれを deny-only にする。SID がそもそも存在しなかった場合も、プログラムはそのケースを記録する。整合性レベルは Medium に設定される。

親とリーフは意図的に一致しない DACL を持っている。現在のユーザーはディレクトリに対して以下を受け取る:

FILE_GENERIC_READ |
FILE_GENERIC_WRITE |
FILE_GENERIC_EXECUTE |
DELETE

既存のファイルは FILE_GENERIC_READ を受け取り、その DACL は継承から保護されている。SYSTEM と Administrators はフルコントロールを保持している。トークンの Administrators SID が存在しないか deny-only であるため、Administrators の許可 ACE はこのスレッドにアクセスを付与できない。

親の DELETE ビットは、それが適用されるオブジェクトを明示するまでは疑わしく見える。これはディレクトリ自体の削除を許可する。その子の 1 つを削除することは FILE_DELETE_CHILD であり、親 ACE には含まれない別のビットである。DeleteFileW は、リーフの DELETE か、親の delete-child 権限のいずれかを受け入れる。このテストはどちらも持っていない。だからこそ error 5 が期待される制御結果なのである。

私は親に FILE_GENERIC_WRITE を残した。その FILE_WRITE_DATA ビットは、オブジェクトがディレクトリの場合 FILE_ADD_FILE になる。呼び出し元は子を作成できるため、親は CfCreatePlaceholders の文書化された WRITE_DATA または WRITE_DAC 要件を満たす。この権限がなければ、API は私が報告したケースに到達する前にベースディレクトリのチェックで失敗する。

このブロックが真でなければ、プログラムは sync root を登録しない:

write open denied with ERROR_ACCESS_DENIED
DeleteFileW denied with ERROR_ACCESS_DENIED
read open succeeded
leaf DACL protected
starting object not a reparse point

ここで停止させたのは、リーフがすでに書き込み可能、削除可能、または reparse point であったなら、実行の後半で S_OK が出ても無意味だからである。

これらの制御の後、プログラムは親を sync root として登録し、終端エントリのみを含むコールバックテーブルで接続し、フラグ 0x4 を付けて既存のファイル名を送信する:

placeholder.RelativeFileName = leaf_name;
placeholder.FsMetadata.BasicInfo = basic_info;
placeholder.FsMetadata.FileSize = standard_info.EndOfFile;
placeholder.FileIdentity = &run_id;
placeholder.FileIdentityLength = sizeof(run_id);
placeholder.Flags = CF_CREATE_SUPERSEDE;

create_hr = cf.Create(root, &placeholder, 1, 0, &processed);

CF_PLACEHOLDER_CREATE_FLAG_SUPERSEDEは、既存のプレースホルダーを上書きすると文書化されている。このファイルはプレースホルダーではない。PoC はリーフ DACL を適用する前に FILE_ATTRIBUTE_NORMAL を設定し、Cloud Files を呼び出す前に reparse-point ビットがクリアであることを確認する。

影響を受けるシステムでは、バッチ呼び出しとエントリの両方が S_OK を返し、CreateUsn は非ゼロであった。ファイルは reparse-point 属性を獲得した。ファイルシステムに reparse データを要求すると、タグ 0x9000001A、すなわち IO_REPARSE_TAG_CLOUD が返された。

EntriesProcessed == 1 は成功を証明しない。API ドキュメントは失敗したエントリもカウントするからである。確認は両方の HRESULT、作成 USN、reparse 属性、および Cloud タグから得られる。

FILE_ID_INFO は呼び出しを通じて変化しなかった。既存のファイルオブジェクトが Cloud Files の状態を獲得したのであり、別のファイルが同じパス名の下に単に現れたのではない。

MSRC がリストする最も古い影響ビルドは 17763.0、Windows 10 version 1809 および Windows Server 2019 世代である。これは公開された痕跡を 2018 年、2026 年 9 月の修正のほぼ 8 年前に位置づける。