MSDN की प्रक्रिया सुरक्षा और पहुँच अधिकार लेख में एक दिलचस्प टिप्पणी है:
... यदि प्रक्रिया A के पास PROCESS_DUP_HANDLE पहुंच के साथ B को संसाधित करने का एक हैंडल है, तो यह प्रक्रिया B के लिए छद्म हैंडल को डुप्लिकेट कर सकता है। यह एक ऐसा हैंडल बनाता है जिसकी प्रक्रिया B तक अधिकतम पहुंच है।
यदि आप स्वतंत्र रूप से रूसी में इसका अनुवाद करते हैं, तो यह यहां कहा गया है कि PROCESS_DUP_HANDLE पहुंच अधिकार के साथ एक प्रक्रिया के लिए एक डिस्क्रिप्टर होने पर, हम इस प्रक्रिया के लिए अधिकतम अनुमत एक्सेस मास्क के साथ डुप्लिकेटहैंडल (...) फ़ंक्शन का उपयोग कर सकते हैं।
प्रदर्शन
इस सुविधा का दोहन करने वाला स्रोत कोड काफी सरल है:
#include <Windows.h> int wmain(int argc, PWSTR argv[]) { HANDLE ProcessAllAccessHandle; HANDLE ProcessDuplicateHandle = OpenProcess(PROCESS_DUP_HANDLE, FALSE, _wtoi(argv[1])); if (ProcessDuplicateHandle) { if (DuplicateHandle(ProcessDuplicateHandle, GetCurrentProcess(), GetCurrentProcess(), &ProcessAllAccessHandle, 0, FALSE, DUPLICATE_SAME_ACCESS)) { CloseHandle(ProcessAllAccessHandle); } CloseHandle(ProcessDuplicateHandle); } return 0; }
संकलन और लिंकिंग के परिणामस्वरूप, हमें एक परीक्षण उपयोगिता मिलती है जो लक्ष्य प्रक्रिया पहचानकर्ता (पीआईडी) को एक तर्क के रूप में लेती है। फिर उपयोगिता PROCESS_DUP_HANDLE अधिकार के साथ निर्दिष्ट प्रक्रिया को खोलता है। इस प्रकार, हम सही PROCESS_DUP_HANDLE (== 0x40) के साथ प्रक्रिया के लिए एक विवरणक की उपलब्धता के लिए आवश्यक शर्त का अनुकरण करते हैं।
एक प्रदर्शन के रूप में, मैं WinDbg में इकट्ठे उपयोगिता का पता लगाऊंगा:
0:000> lsa @$ip 0,3 > 13: if (ProcessDuplicateHandle) 14: { 15: if (DuplicateHandle(ProcessDuplicateHandle, 0:000> !handle @@C++(ProcessDuplicateHandle) 3 Handle 80 Type Process Attributes 0 GrantedAccess 0x40: None DupHandle HandleCount 9 PointerCount 260518
और फिर कलाई का फड़कना डुप्लिकेटहैंडल (...) को कॉल करके हमें एक ही प्रक्रिया के लिए दूसरा विवरणक मिलता है, लेकिन व्यापक अनुमतियों के साथ:
0:000> lsa @$ip 0,3 > 23: CloseHandle(ProcessAllAccessHandle); 24: } 25: CloseHandle(ProcessDuplicateHandle); 0:000> !handle @@C++(ProcessAllAccessHandle) 3 Handle 84 Type Process Attributes 0 GrantedAccess 0x1fffff: Delete,ReadControl,WriteDac,WriteOwner,Synch Terminate,CreateThread,,VMOp,VMRead,VMWrite,DupHandle,CreateProcess,SetQuota,SetInfo,QueryInfo,SetPort HandleCount 10 PointerCount 292877
मुख्य बिंदु ग्रांटेड असफल मूल्य है, जो कि नए विवरणक के लिए 0x1fffff है, जो PROCESS_ALL_ACCESS से मेल खाता है। दुर्भाग्य से, WinDbg लक्ष्य प्रक्रिया के PID को प्रदर्शित नहीं करता है। लेकिन यह सुनिश्चित करने के लिए कि वांछित प्रक्रिया के लिए डिस्क्रिप्टर प्राप्त हुआ है, आप प्रोसेस एक्स्प्लोरर द्वारा डिस्क्रिप्टर को देख सकते हैं (डिबगर में कमांड लाइन के तर्कों में निर्दिष्ट पीआईडी निर्दिष्ट करें):
0:000> dx argv[1] argv[1] : 0x1b7c2e2412c : "21652" [Type: wchar_t *]
स्क्रीनशॉट में, उपयोगिता नोटपैड को चलाने के लिए विवरणकर्ताओं को खोलता है।
ऐसा क्यों हो रहा है?
सबसे पहले, क्योंकि डिस्क्रिप्टर को डुप्लिकेट करते समय, यदि ऑब्जेक्ट के लिए एक्सेस मास्क का विस्तार नहीं किया गया है (और ऑपरेशन फ्लैग DUPLICATE_SAME_ACCESS हमारे लिए विशेष रूप से निर्दिष्ट है), तो कोई सत्यापन नहीं है कि प्रक्रिया (जिसमें डुप्लिकेट किए गए डिस्क्रिप्टर बनाया जाएगा) की इस ऑब्जेक्ट तक पहुंच है। यह केवल जांचा जाता है कि प्रक्रिया विवरणकर्ता डुप्लिकेटहैंडल (...) फ़ंक्शन में पास हुए हैं, जिनके पास अनुमत एक्सेस मास्क PROCESS_DUP_HANDLE है । और फिर प्रक्रियाओं के बीच के डिस्क्रिप्टर की प्रतिलिपि एक्सेस अधिकारों की जांच किए बिना होती है (मैं दोहराता हूं: यदि नए डिस्क्रिप्टर के पास मूल डुप्लिकेट किए गए डिस्क्रिप्टर की तुलना में व्यापक नहीं है)।
और फिर यह ध्यान दिया जाना चाहिए कि GetCurrentProcess () के लिए कॉल एक निरंतरता देता है, वही छद्म विवरणक (छद्म संभाल) इस प्रकाशन की शुरुआत में उल्लेख किया गया है। निरंतर मान के साथ दो प्रलेखित छद्म विवरणकर्ता हैं जो प्रक्रिया विवरणक तालिका से भौतिक रूप से गायब हैं। लेकिन ये डिस्क्रिप्टर सभी कर्नेल फ़ंक्शंस द्वारा संसाधित किए जाते हैं (प्रक्रिया डिस्क्रिप्टर टेबल से सामान्य डिस्क्रिप्टर के साथ):
यह NtCurrentProcess (== -1) का मान है जो GetCurrentProcess () कॉल को लौटाता है।
किसी विशिष्ट प्रक्रिया के ढाँचे में इस छद्म विवरणक का अर्थ है इस प्रक्रिया का एक उद्देश्य अधिकार PROCESS_ALL_ACCESS (वास्तव में, वहाँ बारीकियाँ हैं, लेकिन लेख उनके बारे में नहीं है)। यह स्वयं के लिए इस तरह के लिंक को बदल देता है, लेकिन विवरणकर्ता के माध्यम से:
यही है, डुप्लिकेटहैंडल (प्रोसेसडुप्लिकेटहैंडल, गेटक्रीटप्रोसेस (), ...) के लिए हमारी कॉल की व्याख्या इस प्रकार की जाएगी: ओपन (लक्ष्य) प्रक्रिया से, मान -1 के साथ हैंडल को डुप्लिकेट करें। और लक्ष्य प्रक्रिया के लिए (जिसके पास हमारे पास वैरिएंट प्रोसेस डुप्लीकेटहैंडल में संग्रहीत डिस्क्रिप्टर है), मान -1 PROCESS_ALL_ACCESS अधिकारों के साथ इसी लक्ष्य प्रक्रिया को संदर्भित करेगा। इसलिए, परिणामस्वरूप, हमें अधिकतम अधिकारों के साथ लक्ष्य प्रक्रिया के लिए एक विवरणक मिलता है।
एक उपसंहार के बजाय
मैं बहुत शुरुआत में लिखा गया विचार दोहराता हूं: अगर किसी को PROCESS_DUP_HANDLE के साथ प्रक्रिया के लिए एक डिस्क्रिप्टर प्राप्त होता है, तो Windows सुरक्षा मॉडल के तहत वह उसी प्रक्रिया के लिए एक और डिस्क्रिप्टर प्राप्त कर सकेगा, लेकिन PROCESS_ALL_ACCESS के अधिकारों के साथ (और जो कुछ भी वह इस प्रक्रिया से प्रसन्न होता है) )।
प्रकाशन को अंत तक पढ़ने वाले सभी को धन्यवाद। मैं सभी को सर्वेक्षण के लिए यह पता लगाने के लिए आमंत्रित करता हूं कि इस तरह के प्रकाशन दर्शकों के लिए कैसे दिलचस्प / उपयोगी हो सकते हैं।