ओवरराइटिंग मेमोरी - क्यों?

Win32 एपीआई के आंतों में बहुत संक्षिप्त विवरण के साथ एक SecureZeroMemory फ़ंक्शन है , जिसमें से यह फ़ंक्शन इस कार्य को शून्य के साथ मेमोरी क्षेत्र को ओवरराइट करता है और इस तरह से डिज़ाइन किया गया है कि कोड को अनुकूलित करते समय कंपाइलर कभी भी इस फ़ंक्शन को कॉल नहीं हटाता है। यह भी कहता है कि आपको इस फ़ंक्शन के साथ पासवर्ड और क्रिप्टोग्राफ़िक कुंजियों को संग्रहीत करने के लिए पहले उपयोग की गई मेमोरी को अधिलेखित करना चाहिए।

एक प्रश्न शेष है - यह क्यों है? आप स्वैप फ़ाइल, हाइबरनेट फ़ाइल या क्रैश डंप पर प्रोग्राम मेमोरी लिखने के जोखिम के बारे में लंबी बहस पा सकते हैं, जहां एक हमलावर इसे पा सकता है। यह व्यामोह के समान है - हर हमलावर को इन फाइलों पर हाथ रखने का अवसर नहीं है।

वास्तव में, डेटा तक पहुंचने के बहुत अधिक अवसर हैं जो प्रोग्राम को ओवरराइट करना भूल गया है - कभी-कभी आपको मशीन तक पहुंचने की भी आवश्यकता नहीं होती है। आगे हम एक उदाहरण पर विचार करेंगे, और हर कोई यह तय करेगा कि व्यामोह कितना उचित है।

सभी उदाहरण सी + + के समान संदिग्ध रूप से छद्मकोड में होंगे। कई पत्र होंगे और बहुत साफ कोड नहीं होगा, फिर यह स्पष्ट हो जाएगा कि क्लीनर कोड में स्थिति बहुत बेहतर नहीं है।

So. दूर के कार्य में, हमें एन्क्रिप्शन कुंजी, पासवर्ड या क्रेडिट कार्ड नंबर (इसके बाद - बस एक रहस्य) मिलता है, इसका उपयोग करें और इसे अधिलेखित न करें:

 { const int secretLength = 1024; WCHAR secret[secretLength] = {}; obtainSecret( secret, secretLength ); processWithSecret( what, secret, secretLength ); } 

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

आमतौर पर, आरपीसी का उपयोग करने के लिए, आपको एक आईडीएल इंटरफ़ेस विवरण लिखना होगा। यह इस तरह से कुछ की एक विधि का वर्णन करेगा:

 //MAX_FILE_PATH == 1024 error_status_t rpcRetrieveFile( [in] const WCHAR fileName[MAX_FILE_PATH], [out] BYTE_PIPE filePipe ); 

यहां दूसरा पैरामीटर एक विशेष प्रकार का है, जो मनमानी लंबाई के डेटा धाराओं को प्रसारित करना संभव बनाता है। पहला पैरामीटर फ़ाइल नाम के तहत वर्णों की एक सरणी है।

यह विवरण MIDL संकलक द्वारा संकलित किया गया है, जिसके परिणामस्वरूप फ़ंक्शन के साथ एक हेडर फ़ाइल (.h) है

 error_status_t rpcRetrieveFile ( handle_t IDL_handle, const WCHAR fileName[1024], BYTE_PIPE filePipe); 

यहां MIDL ने एक उपयोगिता पैरामीटर जोड़ा, और दूसरा और तीसरा पैरामीटर पिछले विवरण के समान हैं।

हम इस फ़ंक्शन को कहते हैं:

 void retrieveFile( handle_t binding ) { WCHAR remoteFileName[MAX_FILE_PATH]; retrieveFileName( remoteFileName, MAX_FILE_PATH ); CBytePipeImplementation pipe; rpcRetrieveFile( binding, remoteFileName, pipe ); } 

सबकुछ ठीक है - पुनः प्राप्त करें (नाम) MAX_FILE_PATH - 1 से अधिक नहीं की लंबाई के साथ एक पंक्ति प्राप्त करता है, एक शून्य चरित्र (आप अशक्त चरित्र को नहीं भूल गए) द्वारा समाप्त किया जाता है, कहा जाता है कि पार्टी लाइन के साथ काम करती है - पूर्ण पथ प्राप्त करती है, इसे खोलती है और इससे डेटा स्थानांतरित करती है।

हर कोई आशावाद से भरा है, उत्पाद के कई रिलीज इस कोड के साथ किए जाते हैं, लेकिन किसी ने अभी तक हाथी पर ध्यान नहीं दिया है। हाथी यहाँ। C ++ परिप्रेक्ष्य से, एक फ़ंक्शन पैरामीटर

 const WCHAR fileName[1024] 

यह एक सरणी नहीं है, लेकिन सरणी के पहले तत्व के लिए एक सूचक है। RpcRetrieveFile () फ़ंक्शन केवल एक परत है जो उसी MIDL द्वारा बनाई गई है। यह अपने सभी मापदंडों को पैक करता है और हमेशा एक ही WinAPI NdrClientCall2 () फ़ंक्शन को कॉल करता है, जिसका अर्थ है "विंडोज, कृपया इन मापदंडों के साथ एक आरपीसी कॉल करें," और मापदंडों को NdrClientCall2 () फ़ंक्शन की सूची में पास करता है। पहले मापदंडों में से एक MIDL द्वारा उत्पन्न प्रारूप स्ट्रिंग है जैसा कि IDL में वर्णित है। बहुत अच्छे पुराने प्रिंटफ () के समान।

NdrClientCall2 () ध्यान से प्राप्त प्रारूप स्ट्रिंग को देखता है और ट्रांसमिशन के मापदंडों को दूसरी तरफ पैक करता है (इसे मार्शलिंग कहा जाता है)। प्रत्येक पैरामीटर के आगे इसके प्रकार का संकेत दिया जाता है - प्रत्येक पैरामीटर प्रकार के आधार पर पैक किया जाता है। हमारे मामले में, फ़ाइलनाम पैरामीटर के लिए, सरणी के पहले तत्व का पता निर्दिष्ट है और प्रकार "प्रकार का 1024 तत्वों का एक सरणी" है।

अब कोड में हम एक पंक्ति में दो कॉल मिलते हैं:

 processWithSecret( whatever ); retrieveFile( binding ); 

ProcessWithSecret () फ़ंक्शन स्टैक पर एक गुप्त भंडारण के लिए 2 किलोबाइट खाती है, और समाप्त होने पर उनके बारे में भूल जाती है। अगला, पुनः प्राप्त () फ़ंक्शन कहा जाता है, यह फ़ाइल नाम को 18 वर्णों की लंबाई (18 वर्ण + अंतिम शून्य - केवल 19, यानी 38 बाइट्स) के साथ पुनर्प्राप्त करता है। फ़ाइल नाम को फिर से स्टैक पर संग्रहीत किया जाता है और सबसे अधिक संभावना है, यह ठीक उसी मेमोरी क्षेत्र होगा जिसे पहले फ़ंक्शन में गुप्त रूप से उपयोग किया गया था।

फिर एक रिमोट कॉल होता है और पैकेजिंग फ़ंक्शन एक पैकेट में पूरे अरेंजमेंट (38 बाइट्स नहीं, बल्कि 2048) को पैक करता है और इस पैकेट को फिर नेटवर्क पर प्रसारित किया जाता है।

अत्यधिक अनपेक्षित

गुप्त नेटवर्क पर प्रसारित होता है। कार्यक्रम ने कभी भी नेटवर्क पर रहस्य को प्रसारित करने की योजना नहीं बनाई थी, लेकिन यह प्रसारित होता है। इस तरह के दोष पृष्ठ फ़ाइल को देखने की तुलना में "उपयोग" करने के लिए बहुत अधिक सुविधाजनक हो सकते हैं। अब कौन पागल है?

ऊपर का उदाहरण जटिल लगता है। यहाँ एक समान कोड है जिसे आप codepad.org पर आज़मा सकते हैं

 const int bufferSize = 32; void first() { char buffer[bufferSize]; memset( buffer, 'A', sizeof( buffer ) ); } void second() { char buffer[bufferSize]; memset( buffer, 'B', bufferSize / 2 ); printf( "%s", buffer ); } int main() { first(); second(); } 

इसका अस्पष्ट व्यवहार है। पोस्ट लिखने के समय, कार्य का परिणाम 16 वर्णों 'बी' और 16 वर्ण 'ए' की एक स्ट्रिंग है।

अब पिचकारी और टार्च लहराए जाने और गुस्सा निकालने के लिए समय आ गया है कि कोई भी व्यक्ति अपने दिमाग में सामान्य सरणियों का उपयोग नहीं करता है, जिसे आपको std :: वेक्टर, std :: string और यूनिवर्सल यूनिवर्सल क्लास का उपयोग करने की आवश्यकता है, जो स्मृति के साथ सही ढंग से काम करते हैं, और पवित्र युद्ध 9 हजार से कम नहीं टिप्पणियाँ।

वास्तव में, यह यहां मदद नहीं करेगा - आरपीसी के आंत्र में पैकेजिंग फ़ंक्शन अभी भी वहां लिखे गए कॉलिंग कोड की तुलना में अधिक डेटा पढ़ेगा। नतीजतन, निकटतम पतों पर डेटा पढ़ा जाएगा, या (कुछ मामलों में) यदि मेमोरी गलत तरीके से एक्सेस की गई थी तो विफलता होगी। इन निकटतम पतों में फिर से डेटा हो सकता है जो नेटवर्क पर प्रसारित नहीं किया जा सकता है।

यहां किसे दोष देना है? हमेशा की तरह, डेवलपर को दोष देना है - उसने गलत समझा कि rpcRetrieveFile () फ़ंक्शन प्राप्त मापदंडों के साथ कैसे काम करता है। परिणाम अपरिभाषित व्यवहार है, जो इस मामले में नेटवर्क पर अनियंत्रित डेटा ट्रांसमिशन की ओर जाता है। यह RPC इंटरफ़ेस को बदलकर या दोनों तरफ कोड को संपादित करके या पर्याप्त रूप से बड़े आकार के एक सरणी का उपयोग करके और इसमें पैरामीटर को कॉपी करने से पहले इसे पूरी तरह से पुन: लिखकर तय किया जा सकता है।

SecureZeroMemory () इस स्थिति में मदद करेगा - यदि पहला फ़ंक्शन पूरा होने से पहले रहस्य को फिर से लिखता है, तो दूसरे में त्रुटि कम से कम फिर से लिखे गए सरणी के हस्तांतरण की ओर ले जाएगी। डार्विन पुरस्कार मिलना कठिन है।

दिमित्री मेश्चेरीकोव,
डेवलपर उत्पाद विभाग