फ़ाइल ने मना किया। क्लाउड फ़ाइलों ने अधिकार प्राप्त कर लिया।

CVE-2026-83991 एक Windows Cloud Files छेड़छाड़ भेद्यता है जिसकी प्रकाशित प्रभावित सीमा Windows 10 संस्करण 1809 से शुरू होती है, जो सितंबर 2026 के फिक्स से लगभग आठ साल पहले है।

मैंने Windows से एक फ़ाइल को लिखने के लिए खोलने को कहा। उसने ERROR_ACCESS_DENIED उत्तर दिया।

मैंने Windows से उसी फ़ाइल को हटाने को कहा। फिर से, ERROR_ACCESS_DENIED।

फिर मैंने Cloud Files स्टैक से उस फ़ाइलनाम को प्रतिस्थापित (supersede) करने को कहा। उसने S_OK लौटाया और मौजूदा फ़ाइल को Cloud Files प्लेसहोल्डर में बदल दिया।

फ़ाइल ने दो बार मना किया था। प्रतिस्थापन पथ ने "कृपया आगे बढ़ें" के करीब कुछ सुना।

वह प्राधिकरण विभाजन ही CVE-2026-83991 है। Microsoft इसे Windows Cloud Files Mini Filter Driver Tampering Vulnerability कहता है, इसे Important दर्जा देता है, और CVSS 3.1 आधार स्कोर 5.5 Medium निर्धारित किया है। आधिकारिक वेक्टर CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N/E:U/RL:O/RC:C है।

संक्षिप्त संस्करण

प्रूफ ऑफ कॉन्सेप्ट एक नई निर्देशिका और एक साधारण फ़ाइल बनाता है। यह कॉलर को निर्देशिका पर लिखने की पहुंच देता है, फिर फ़ाइल पर एक सुरक्षित DACL लागू करता है जो कॉलर को सामान्य लिखने या हटाने की पहुंच के बिना केवल पढ़ने की पहुंच प्रदान करता है।

एक प्रतिबंधित मध्यम-अखंडता थ्रेड टोकन का उपयोग करके, यह निम्नलिखित अनुक्रम साबित करता है:

कॉल ने एक प्रविष्टि संसाधित की, एक गैर-शून्य निर्माण USN लौटाया, और फ़ाइल को IO_REPARSE_TAG_CLOUD टैग, मान 0x9000001A दिया। पुनरुत्पादित रन में, कॉल से पहले और बाद में फ़ाइल ID समान थी। वही NTFS फ़ाइल बनी रही जबकि उसकी स्थिति क्लाउड प्लेसहोल्डर में बदल गई।

Cloud Files का एक छोटा नक्शा

Windows 10 संस्करण 1709 ने Cloud Files API पेश किया। यह डेस्कटॉप सिंक इंजनों को एक निर्देशिका ट्री पंजीकृत करने, प्लेसहोल्डर प्रविष्टियाँ बनाने और आवश्यकता पड़ने पर उनकी सामग्री को हाइड्रेट करने का एक समर्थित तरीका देता है।

यहाँ तीन चीज़ें मायने रखती हैं:

• CldApi.dll यूज़र-मोड क्लाउड फ़िल्टर API उजागर करता है।
• cldflt.sys स्टोरेज पथ के केंद्र में फ़ाइल-सिस्टम मिनीफ़िल्टर है।
• एक सिंक रूट एक पंजीकृत निर्देशिका ट्री है जिसे एक सिंक प्रदाता प्रबंधित करता है।

क्लाउड प्लेसहोल्डर रिपार्स पॉइंट का उपयोग करते हैं। रिपार्स पॉइंट एक फ़ाइल-सिस्टम तंत्र है जिसमें एक टैग और संबद्ध डेटा होता है। यह सिंबोलिक लिंक से एक व्यापक अवधारणा है, और दोनों को पर्यायवाची नहीं माना जाना चाहिए।

प्रासंगिक API CfCreatePlaceholders है। यह एक पंजीकृत सिंक रूट के नीचे एक या अधिक प्लेसहोल्डर फ़ाइलें या निर्देशिकाएँ बनाता है। Microsoft का दस्तावेज़ कहता है कि कॉलर के पास आधार निर्देशिका तक WRITE_DATA या WRITE_DAC पहुंच होनी चाहिए।

प्रति-प्रविष्टि फ़्लैग CF_PLACEHOLDER_CREATE_FLAG_SUPERSEDE, मान 0x4, मौजूदा प्लेसहोल्डर के लिए अधिलेखन शब्दार्थ प्रदान करता है। इस CVE में दिलचस्प विवरण यह है कि भेद्य पथ ने एक साधारण मौजूदा फ़ाइल को भी स्वीकार किया और उसे प्लेसहोल्डर में बदल दिया।

पैरेंट अधिकार लीफ अधिकार नहीं है

प्रयोग निर्देशिका पर अधिकारों को मौजूदा फ़ाइल पर अधिकारों से अलग करता है।

पैरेंट निर्देशिका वर्तमान उपयोगकर्ता को अनुदान देती है:

FILE_GENERIC_READ
FILE_GENERIC_WRITE
FILE_GENERIC_EXECUTE
DELETE

एक निर्देशिका के लिए, FILE_GENERIC_WRITE में FILE_WRITE_DATA शामिल है, जिसे FILE_ADD_FILE भी कहा जाता है। यह CfRegisterSyncRoot और CfCreatePlaceholders द्वारा उपयोग की जाने वाली प्रलेखित आधार-निर्देशिका आवश्यकता के लिए पर्याप्त है।

पैरेंट ACE FILE_DELETE_CHILD अनुदान नहीं देता। इसका DELETE बिट पैरेंट ऑब्जेक्ट पर ही लागू होता है। यह अंतर मायने रखता है क्योंकि DeleteFileW के लिए लक्ष्य फ़ाइल पर DELETE या उसके पैरेंट पर FILE_DELETE_CHILD की आवश्यकता होती है।

मौजूदा लीफ वर्तमान उपयोगकर्ता को केवल FILE_GENERIC_READ अनुदान देता है। इसका DACL PROTECTED_DACL_SECURITY_INFORMATION के साथ सुरक्षित चिह्नित है, इसलिए यह पैरेंट के ACE विरासत में नहीं लेता।

यह केंद्रीय प्रश्न बनाता है:

क्या किसी निर्देशिका में एक नया चाइल्ड बनाने की अनुमति किसी अधिक प्रतिबंधात्मक मौजूदा चाइल्ड के विरुद्ध स्थिति-परिवर्तनकारी प्रतिस्थापन ऑपरेशन को भी अधिकृत करती है?

साधारण फ़ाइल पहुंच नहीं उत्तर देती। भेद्य Cloud Files पथ ने हाँ उत्तर दिया।

Microsoft का फ़ाइल सुरक्षा दस्तावेज़ बताता है कि अंतर की अपेक्षा क्यों की जाती है। किसी फ़ाइल तक पहुंच सामान्यतः उस फ़ाइल के सुरक्षा विवरणक द्वारा नियंत्रित होती है। पैरेंट का विवरणक सामान्यतः चाइल्ड की पहुंच जांच को प्रतिस्थापित नहीं करता, विरासत और FILE_DELETE_CHILD जैसे विशिष्ट नियमों के अलावा।

टोकन वहीं रहता है

पहुंच-नियंत्रण प्रदर्शन असंबद्ध हो जाते हैं जब सेटअप एक पहचान के रूप में चलता है और दिलचस्प ऑपरेशन दूसरे के रूप में चलता है। यह PoC उस समस्या से बचता है।

यह वर्तमान प्रक्रिया टोकन से एक प्रतिबंधित टोकन प्राप्त करता है, Administrators SID को अनुपस्थित या केवल-अस्वीकार बनाता है, मध्यम अखंडता सेट करता है, SecurityImpersonation पर एक प्रतिरूपण टोकन डुप्लिकेट करता है, और इसे SetThreadToken के साथ वर्तमान थ्रेड पर स्थापित करता है।

सटीक विशेषाधिकार शब्दावली पर ध्यान देने की आवश्यकता है। CreateRestrictedToken DISABLE_MAX_PRIVILEGE के साथ SeChangeNotifyPrivilege को छोड़कर हर विशेषाधिकार अक्षम कर देता है। वह शेष विशेषाधिकार कुछ निर्देशिका ट्रैवर्सल जांचों को बायपास करता है। यह फ़ाइल डेटा लेखन या विलोपन अधिकार नहीं देता।

PoC फिर सेटअप, नियंत्रण जांच, सिंक-रूट पंजीकरण, कनेक्शन और प्रतिस्थापन कॉल करता है जबकि वही थ्रेड प्रतिरूपण टोकन सक्रिय रहता है। "पहुंच अस्वीकृत" और S_OK के बीच कोई सुविधाजनक पहचान स्वैप नहीं है।

PoC के माध्यम से चलना

पूर्ण स्रोत main_poc.c में है, GCC या Microsoft के C कंपाइलर के लिए build.bat के साथ।

1. एक नए नामस्थान से शुरू करें

प्रोग्राम वर्तमान उपयोगकर्ता की स्थानीय एप्लिकेशन-डेटा निर्देशिका के नीचे एक नई GUID-नामित परीक्षण निर्देशिका बनाता है। एक वैकल्पिक पथ प्रदान किया जा सकता है, लेकिन प्रोग्राम उस पथ का उपयोग करने से इनकार करता है जो पहले से मौजूद है।

वह प्रतिबंध जानबूझकर है। PoC उस डेटा के विरुद्ध बग प्रदर्शित करता है जिसे वह स्वयं बनाता है। इसे किसी स्थापित तृतीय-पक्ष सिंक प्रदाता की आवश्यकता नहीं है और यह किसी मौजूदा सिंक रूट को लक्षित नहीं करता।

2. एक साधारण फ़ाइल बनाएं

प्रोग्राम protected_existing.bin बनाता है, ज्ञात परीक्षण डेटा लिखता है, और इसे साधारण फ़ाइल विशेषताएँ देता है। यह फ़ाइल का मूल मेटाडेटा, तार्किक आकार, विशेषताएँ और फ़ाइल ID रिकॉर्ड करता है।

Cloud Files कॉल से पहले, फ़ाइल एक रिपार्स पॉइंट नहीं है।

3. DACL लागू करें और सत्यापित करें

प्रोग्राम लीफ DACL को तीन गैर-विरासत अनुमति ACE के साथ प्रतिस्थापित करता है:

क्योंकि प्रभावी टोकन में Administrators SID अनुपस्थित या केवल-अस्वीकार है, Administrators अनुमति ACE थ्रेड को व्यवस्थापक पहुंच प्रदान नहीं कर सकता।

PoC फिर तीन नियंत्रण करता है। GENERIC_WRITE त्रुटि 5 के साथ विफल होता है, DeleteFileW त्रुटि 5 के साथ विफल होता है, और GENERIC_READ सफल होता है। यह भी पुष्टि करता है कि DACL सुरक्षित है।

वे नियंत्रण दो साधारण ऑपरेशनों द्वारा उपयोग की जाने वाली अनुमतियाँ साबित करते हैं। PoC WRITE_DAC या हर संभव तरीके का परीक्षण नहीं करता जिससे उसकी सिंथेटिक परीक्षण फ़ाइल का स्वामी उस फ़ाइल को प्रभावित कर सके। प्रदर्शित विसंगति विशेष रूप से अस्वीकृत लेखन और विलोपन ऑपरेशनों और सफल Cloud Files प्रतिस्थापन ऑपरेशन के बीच है।

4. एक न्यूनतम सिंक प्रदाता बनें

PoC अपनी नई निर्देशिका को प्रगतिशील हाइड्रेशन नीति और पूर्ण जनसंख्या नीति के साथ पंजीकृत करता है। यह प्रदाता और रूट पहचान के रूप में एक नया GUID प्रदान करता है।

फिर यह केवल समाप्त करने वाली CF_CALLBACK_NONE प्रविष्टि वाली कॉलबैक तालिका के साथ CfConnectSyncRoot कॉल करता है। परीक्षण किए जा रहे मेटाडेटा संक्रमण के लिए किसी हाइड्रेशन कॉलबैक की आवश्यकता नहीं है।

5. प्रतिस्थापन के लिए पूछें

प्लेसहोल्डर प्रविष्टि मूल फ़ाइल के टाइमस्टैम्प और तार्किक आकार को संरक्षित करती है, एक GUID फ़ाइल पहचान प्रदान करती है, और आधिकारिक प्रतिस्थापन फ़्लैग से मैप होने वाले स्थानीय स्थिरांक को सेट करती है:

#define CF_CREATE_SUPERSEDE 0x00000004UL

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);

स्रोत CldApi.dll को गतिशील रूप से लोड करता है और सार्वजनिक फ़ंक्शनों को रनटाइम पर हल करता है। इसकी हाथ-घोषित संरचनाएँ केवल इस परीक्षण के लिए आवश्यक ABI को कवर करती हैं।

6. बहुत जल्दी जश्न मनाने से इनकार करें

एक बैच API एक प्रविष्टि संसाधित कर सकता है जो विफल रही। Microsoft का दस्तावेज़ स्पष्ट रूप से कहता है कि EntriesProcessed में विफल प्रविष्टियाँ शामिल हैं, इसलिए एक का मान अपने आप में सफलता स्थापित नहीं करता।

इसलिए PoC को CONFIRMED प्रिंट करने और कोड शून्य के साथ बाहर निकलने से पहले इन सभी शर्तों की आवश्यकता होती है:

• CfCreatePlaceholders बिल्कुल S_OK लौटाता है।
• व्यक्तिगत प्रविष्टि परिणाम बिल्कुल S_OK है।
• एक प्रविष्टि संसाधित हुई।
• निर्माण USN गैर-शून्य है।
• परिणामी फ़ाइल मौजूद है और उसमें FILE_ATTRIBUTE_REPARSE_POINT है।
• FSCTL_GET_REPARSE_POINT IO_REPARSE_TAG_CLOUD लौटाता है।

प्रत्यक्ष लेखन, विलोपन, पठन, DACL और पूर्व-मौजूदा-फ़ाइल जांच भी प्रोग्राम में पहले पास होनी चाहिए, अन्यथा Cloud Files ऑपरेशन से पहले निष्पादन रुक जाता है।

डिस्क पर क्या बदला

पुनरुत्पादित स्थिति संक्रमण था:

0x00000020 FILE_ATTRIBUTE_ARCHIVE है। परिणामी 0x00401600 मास्क में FILE_ATTRIBUTE_SPARSE_FILE, FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_OFFLINE और FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS शामिल हैं।

अपरिवर्तित फ़ाइल ID विशेष रूप से उपयोगी है। यह दिखाता है कि, इस रन में, परिणाम केवल उसी पथनाम पर दिखाई देने वाली एक अलग फ़ाइल नहीं थी। मौजूदा फ़ाइल ऑब्जेक्ट Cloud Files स्थिति प्राप्त करते हुए बच गया।

प्रोग्राम तार्किक फ़ाइल आकार को संरक्षित करता है, लेकिन यह रूपांतरण के बाद मूल बाइट्स को मान्य नहीं करता। इस PoC से मनमानी सामग्री नियंत्रण के बारे में कोई दावा नहीं निकलता।

प्राधिकरण विफलता कहाँ स्थित है

अवलोकनीय विफलता को आंतरिक कॉल स्टैक का आविष्कार किए बिना बताया जा सकता है:

1. कॉलर के पास आधार निर्देशिका पर उसे पंजीकृत करने और चाइल्ड बनाने के लिए पर्याप्त अधिकार है।
2. मौजूदा लीफ का वर्तमान DACL परीक्षण किए गए लेखन और विलोपन ऑपरेशनों को अस्वीकार करता है।
3. CfCreatePlaceholders उस लीफ के लिए एक प्रतिस्थापन अनुरोध स्वीकार करता है।
4. CldFlt लीफ को Cloud Files प्लेसहोल्डर में बदल देता है।

यह व्यवहार प्रतिस्थापन पथ पर मौजूदा लीफ के विरुद्ध एक लापता या अपूर्ण जांच के अनुरूप है। यह जिम्मेदार सटीक आंतरिक फ़ंक्शन, शाखा, IRP या कर्नेल कॉलबैक की पहचान नहीं करता। PoC में कोई कर्नेल डिबगिंग या बाइनरी-अंतर विश्लेषण नहीं है, इसलिए स्पष्टीकरण बाह्य रूप से सत्यापित सीमा पर रुक जाता है।

Microsoft ने CWE-306, Missing Authentication for Critical Function निर्धारित किया। Windows ऑब्जेक्ट स्तर पर, प्रयोग असंगत प्राधिकरण प्रवर्तन उजागर करता है। मैं मेटाडेटा में Microsoft के आधिकारिक CWE का उपयोग करता हूँ और तकनीकी विश्लेषण में देखे गए पहुंच-नियंत्रण व्यवहार का वर्णन करता हूँ।

प्रभाव, विशेषणों को छोटी पट्टी पर रखते हुए

PoC एक अखंडता और फ़ाइल-स्थिति परिवर्तन प्रदर्शित करता है जो परीक्षण किए गए प्रत्यक्ष ऑपरेशन नहीं कर सके। आवश्यक आधार-निर्देशिका पहुंच वाला एक स्थानीय निम्न-विशेषाधिकार कॉलर प्रभावित पथ के माध्यम से एक मौजूदा केवल-पठनीय लीफ को Cloud Files प्लेसहोल्डर बना सकता है।

Microsoft की सलाह व्यापक उत्पाद प्रभाव देती है: एक हमलावर सुरक्षित सिस्टम डेटा में अनधिकृत परिवर्तन कर सकता है और सामान्य विशेषाधिकारों से परे सिस्टम स्थिति या कॉन्फ़िगरेशन बदल सकता है। यह भेद्यता के बारे में Microsoft का आकलन है। पृथक PoC एक सुरक्षित सिस्टम लक्ष्य का चयन नहीं करता या पूर्ण पोस्ट-एक्सप्लॉइटेशन श्रृंखला प्रदर्शित नहीं करता।

CVSS वेक्टर उसी व्यापक आकार को दर्शाता है:

• स्थानीय हमला वेक्टर
• निम्न हमला जटिलता
• निम्न विशेषाधिकार आवश्यक
• कोई उपयोगकर्ता सहभागिता नहीं
• उच्च अखंडता प्रभाव
• कोई दावा किया गया गोपनीयता या उपलब्धता प्रभाव नहीं

यह कितना पीछे तक जाता है?

सावधान उत्तर Microsoft की प्रकाशित प्रभावित सीमा में लगभग आठ साल है।

आधिकारिक CVE रिकॉर्ड सबसे पुरानी प्रभावित शाखा को Windows 10 संस्करण 1809 और Windows Server 2019 के लिए 10.0.17763.0 पर शुरू करता है। Microsoft का Windows 10 रिलीज़ इतिहास पहला संस्करण 1809 बिल्ड, 17763.1, 2 अक्टूबर 2018 को सूचीबद्ध करता है। Microsoft ने फिक्स 8 सितंबर 2026 को प्रकाशित किया।

यह सार्वजनिक सीमा में सबसे पहले पुष्टि किए गए बिंदु को फिक्स से ठीक आठ साल से कम समय पहले रखता है।

Cloud Files API स्वयं 2017 में Windows 10 संस्करण 1709 के साथ आया, और API दस्तावेज़ 1709 को न्यूनतम समर्थित क्लाइंट के रूप में सूचीबद्ध करता है। यह साबित नहीं करता कि यह भेद्यता 1709 में मौजूद थी। Microsoft का CVE रिकॉर्ड 1709 को सूचीबद्ध नहीं करता, और इस शोध ने इसका परीक्षण नहीं किया। एक API का जन्मदिन स्वचालित रूप से एक बग का जन्मदिन नहीं है, चाहे सुर्खियाँ कितनी भी आकर्षक क्यों न हों।

पुनरुत्पादन

NTFS पर एक प्रभावित परीक्षण प्रणाली का उपयोग करें। PoC को एक सामान्य, गैर-उन्नत कमांड प्रॉम्प्ट से चलाएं।

build.bat
main_poc.exe

बिल्ड स्क्रिप्ट उपलब्ध होने पर MinGW-w64 GCC का उपयोग करती है और Microsoft के C कंपाइलर पर वापस आ जाती है। प्रोग्राम अपना नया परीक्षण रूट बनाता और पंजीकृत करता है। यह सफाई के दौरान अपंजीकृत और डिस्कनेक्ट करता है, फिर निरीक्षण के लिए परीक्षण निर्देशिका को जगह पर छोड़ देता है।

वैकल्पिक पथ रूप है:

main_poc.exe C:\path\to\a\new-test-directory

प्रदान किया गया पथ पहले से मौजूद नहीं होना चाहिए। परीक्षण को पृथक रखें और परिणाम एकत्र करने के बाद उसकी निर्देशिका हटा दें।

एक स्थिर प्रणाली पर, पूर्ण स्थिति CONFIRMED तक नहीं पहुंचनी चाहिए। एक कंसोल लाइन से पैच स्थिति का अनुमान न लगाएं। समग्र परिणाम, निकास कोड, प्रति-प्रविष्टि परिणाम, USN, विशेषताएँ और रिपार्स टैग को एक साथ जांचें।

फ़ाइल को बंद करना

सबसे दिलचस्प Windows भेद्यताएँ अक्सर इस बात पर तर्क होती हैं कि पहुंच जांच वास्तव में किस ऑब्जेक्ट के बारे में थी।

यहाँ, एक निर्देशिका के नीचे बनाने की अनुमति एक ऐसे पथ तक पहुंची जो उसके अंदर पहले से मौजूद एक अधिक प्रतिबंधात्मक चाइल्ड को बदल सकता था। साधारण फ़ाइल API ने उस चाइल्ड के वर्तमान DACL का सम्मान किया। Cloud Files प्रतिस्थापन ने उसी सीमा को संरक्षित नहीं किया।

कोई शानदार मेमोरी भ्रष्टाचार आवश्यक नहीं था। एक ऑब्जेक्ट ने मना किया, दूसरे ऑब्जेक्ट ने जारी रखने के लिए पर्याप्त अधिकार प्रदान किया, और एक परिचित फ़ाइलनाम चुपचाप कुछ और बन गया।

यही पूरी चाल है। यही कारण भी है कि चाल मायने रखती है।