CVE-2026-83991: Ersetzen einer Datei, die der Aufrufer nicht löschen kann

Ich habe diese Zeilen nebeneinander stehen lassen, weil eine Trennung den Fehler komplizierter erscheinen lässt, als er ist:

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

Das schreibende Öffnen, der Löschversuch und der Cloud Files-Aufruf verwenden denselben Pfadnamen und dasselbe Thread-Token. Vor dem letzten Aufruf gehört der Name zu einer gewöhnlichen Datei mit einer geschützten DACL und ohne Reparse-Point. Danach gibt FSCTL_GET_REPARSE_POINT IO_REPARSE_TAG_CLOUD zurück.

Microsoft hat dieses Ergebnis als CVE-2026-83991 veröffentlicht, die Windows Cloud Files Mini Filter Driver Tampering Vulnerability. Ich hatte es im Bericht als fehlerhafte Autorisierung beschrieben und CWE-863 vorgeschlagen. Microsoft hat stattdessen CWE-306 zugewiesen.

Das Programm installiert sein eingeschränktes Impersonation-Token, bevor es das Testverzeichnis, die Datei, die DACLs oder den Sync Root erstellt. Es gibt kein erhöhtes Setup, auf das ein Token-Wechsel nur für den interessanten Aufruf folgt. Wenn das Konto eine Administrators-SID hat, macht CreateRestrictedToken sie deny-only; wenn die SID nie vorhanden war, zeichnet das Programm auch diesen Fall auf. Die Integritätsstufe wird auf Medium gesetzt.

Das übergeordnete Verzeichnis und das Blatt haben bewusst keine übereinstimmenden DACLs. Der aktuelle Benutzer erhält für das Verzeichnis Folgendes:

FILE_GENERIC_READ |
FILE_GENERIC_WRITE |
FILE_GENERIC_EXECUTE |
DELETE

Die vorhandene Datei erhält FILE_GENERIC_READ, und ihre DACL ist vor Vererbung geschützt. SYSTEM und Administrators behalten die vollständige Kontrolle. Da die Administrators-SID des Tokens fehlt oder deny-only ist, kann der Allow-ACE für Administrators diesem Thread keinen Zugriff gewähren.

Das DELETE-Bit am übergeordneten Verzeichnis wirkt verdächtig, bis das Objekt, auf das es sich bezieht, explizit gemacht wird. Es erlaubt das Löschen des Verzeichnisses selbst. Das Löschen eines seiner untergeordneten Elemente ist FILE_DELETE_CHILD, ein anderes Bit, das der ACE des übergeordneten Verzeichnisses nicht enthält. DeleteFileW akzeptiert entweder DELETE am Blatt oder die delete-child-Berechtigung am übergeordneten Verzeichnis. Der Test hat weder das eine noch das andere, weshalb Fehler 5 das erwartete Kontrollergebnis ist.

Ich habe FILE_GENERIC_WRITE am übergeordneten Verzeichnis belassen. Sein FILE_WRITE_DATA-Bit ist FILE_ADD_FILE, wenn das Objekt ein Verzeichnis ist. Der Aufrufer darf ein untergeordnetes Element erstellen, und das übergeordnete Verzeichnis erfüllt daher die dokumentierte WRITE_DATA- oder WRITE_DAC-Anforderung für CfCreatePlaceholders. Ohne dieses Recht scheitert die API an ihrer Basisverzeichnis-Prüfung, bevor sie den von mir gemeldeten Fall erreicht.

Das Programm registriert den Sync Root nur, wenn dieser Block wahr ist:

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

Ich habe es dort anhalten lassen, weil ein S_OK später im Lauf nutzlos wäre, wenn das Blatt bereits beschreibbar, löschbar oder ein Reparse-Point gewesen wäre.

Nach diesen Kontrollen registriert das Programm das übergeordnete Verzeichnis als Sync Root, verbindet es mit einer Callback-Tabelle, die nur den abschließenden Eintrag enthält, und übergibt den vorhandenen Dateinamen mit Flag 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 ist dokumentiert als Überschreiben eines vorhandenen Platzhalters. Diese Datei ist keiner. Das PoC setzt FILE_ATTRIBUTE_NORMAL, bevor es die Blatt-DACL anwendet, und bestätigt, dass das Reparse-Point-Bit klar ist, bevor Cloud Files aufgerufen wird.

Auf dem betroffenen System gaben der Batch-Aufruf und der Eintrag beide S_OK zurück, und CreateUsn war ungleich null. Die Datei erhielt das Reparse-Point-Attribut. Die Abfrage der Reparse-Daten beim Dateisystem gab Tag 0x9000001A zurück, was IO_REPARSE_TAG_CLOUD ist.

EntriesProcessed == 1 beweist keinen Erfolg, weil die API-Dokumentation auch fehlgeschlagene Einträge zählt. Die Bestätigung ergibt sich aus beiden HRESULTs, der Erstellungs-USN, dem Reparse-Attribut und dem Cloud-Tag.

FILE_ID_INFO blieb über den Aufruf hinweg unverändert. Das vorhandene Dateiobjekt erhielt den Cloud Files-Zustand; eine andere Datei erschien nicht bloß unter demselben Pfadnamen.

Der älteste von MSRC aufgeführte betroffene Build ist 17763.0, die Generation Windows 10 Version 1809 und Windows Server 2019. Das verlegt die öffentliche Spur in das Jahr 2018, fast acht Jahre vor dem Fix vom September 2026.