CVE-2026-83991: उस फ़ाइल को supersede करना जिसे कॉलर हटा नहीं सकता

मैंने इन पंक्तियों को एक-दूसरे के बगल में रखा क्योंकि इन्हें अलग करने से बग जितना है उससे अधिक जटिल दिखने लगता है:

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

write open, delete प्रयास, और Cloud Files कॉल एक ही pathname और एक ही thread token का उपयोग करते हैं। अंतिम कॉल से पहले, नाम एक सामान्य फ़ाइल का होता है जिसमें एक संरक्षित DACL होता है और कोई reparse point नहीं होता। इसके बाद, FSCTL_GET_REPARSE_POINT IO_REPARSE_TAG_CLOUD लौटाता है।

Microsoft ने उस परिणाम को CVE-2026-83991, Windows Cloud Files Mini Filter Driver Tampering Vulnerability के रूप में प्रकाशित किया। मैंने रिपोर्ट में इसे गलत प्राधिकरण के रूप में वर्णित किया था और CWE-863 का सुझाव दिया था। Microsoft ने इसके बजाय CWE-306 निर्दिष्ट किया।

प्रोग्राम टेस्ट डायरेक्टरी, फ़ाइल, DACL, या sync root बनाने से पहले अपना प्रतिबंधित impersonation token इंस्टॉल करता है। केवल रुचिकर कॉल के लिए कोई elevated setup के बाद token switch नहीं होता। यदि खाते में Administrators SID है, तो CreateRestrictedToken इसे deny-only बना देता है; यदि SID कभी मौजूद ही नहीं था, तो प्रोग्राम उस स्थिति को भी रिकॉर्ड करता है। Integrity को Medium पर सेट किया गया है।

parent और leaf में जानबूझकर मेल खाते DACL नहीं होते। वर्तमान उपयोगकर्ता को डायरेक्टरी पर यह प्राप्त होता है:

FILE_GENERIC_READ |
FILE_GENERIC_WRITE |
FILE_GENERIC_EXECUTE |
DELETE

मौजूदा फ़ाइल को FILE_GENERIC_READ प्राप्त होता है, और उसका DACL inheritance से संरक्षित होता है। SYSTEM और Administrators पूर्ण नियंत्रण बनाए रखते हैं। चूंकि token का Administrators SID अनुपस्थित या deny-only है, Administrators allow ACE इस thread को एक्सेस प्रदान नहीं कर सकता।

parent पर DELETE बिट संदिग्ध लगता है जब तक कि यह स्पष्ट न कर दिया जाए कि यह किस ऑब्जेक्ट पर लागू होता है। यह डायरेक्टरी को ही हटाने की अनुमति देता है। इसके किसी child को हटाना FILE_DELETE_CHILD है, एक अलग बिट जो parent ACE में मौजूद नहीं है। DeleteFileW या तो leaf पर DELETE या parent पर delete-child अनुमति स्वीकार करता है। टेस्ट में इनमें से कोई भी नहीं है, यही कारण है कि error 5 अपेक्षित नियंत्रण परिणाम है।

मैंने parent पर FILE_GENERIC_WRITE छोड़ दिया। जब ऑब्जेक्ट एक डायरेक्टरी होती है तो इसका FILE_WRITE_DATA बिट FILE_ADD_FILE होता है। कॉलर एक child बना सकता है, और इसलिए parent CfCreatePlaceholders के लिए प्रलेखित WRITE_DATA या WRITE_DAC आवश्यकता को पूरा करता है। उस अधिकार के बिना, API उस केस तक पहुंचने से पहले ही अपनी base-directory जांच में विफल हो जाता है जिसकी मैंने रिपोर्ट की थी।

प्रोग्राम 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

मैंने इसे वहीं रोक दिया क्योंकि यदि leaf पहले से ही writable, deletable, या reparse point होता तो रन में बाद में आने वाला S_OK बेकार होता।

उन नियंत्रणों के बाद, प्रोग्राम parent को sync root के रूप में रजिस्टर करता है, इसे केवल terminating entry वाली callback table के साथ कनेक्ट करता है, और मौजूदा filename को 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 को मौजूदा placeholder को overwrite करने के रूप में प्रलेखित किया गया है। यह फ़ाइल placeholder नहीं है। PoC leaf DACL लागू करने से पहले FILE_ATTRIBUTE_NORMAL सेट करता है और Cloud Files को कॉल करने से पहले पुष्टि करता है कि reparse-point बिट साफ़ है।

प्रभावित सिस्टम पर, batch call और entry दोनों ने S_OK लौटाया, और CreateUsn शून्येतर था। फ़ाइल ने reparse-point attribute प्राप्त कर लिया। फ़ाइल सिस्टम से reparse डेटा मांगने पर tag 0x9000001A लौटा, जो IO_REPARSE_TAG_CLOUD है।

EntriesProcessed == 1 सफलता सिद्ध नहीं करता क्योंकि API दस्तावेज़ विफल entries को भी गिनता है। पुष्टि दोनों HRESULT, creation USN, reparse attribute, और Cloud tag से होती है।

FILE_ID_INFO कॉल के दौरान अपरिवर्तित रहा। मौजूदा फ़ाइल ऑब्जेक्ट ने Cloud Files state प्राप्त कर लिया; उसी pathname के अंतर्गत कोई अन्य फ़ाइल महज़ प्रकट नहीं हुई।

MSRC की सबसे पुरानी सूचीबद्ध प्रभावित build 17763.0 है, जो Windows 10 version 1809 और Windows Server 2019 पीढ़ी है। यह सार्वजनिक ट्रेल को 2018 में रखता है, सितंबर 2026 के फिक्स से लगभग आठ साल पहले।