एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 7: मूल ग्राहक सैंडबॉक्स, भाग 3

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल

कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषयों में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।

व्याख्यान 1: "परिचय: खतरे के मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 2: "हैकर हमलों का नियंत्रण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 4: "पृथक्करण का पृथक्करण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?" भाग 1 / भाग 2
व्याख्यान 6: "अवसर" भाग 1 / भाग 2 / भाग 3
व्याख्यान 7: "मूल ग्राहक सैंडबॉक्स" भाग 1 / भाग 2 / भाग 3

नियम C4 में एक कैविएट है। आप एक कार्यक्रम के अंत में "कूद" नहीं सकते। आखिरी चीज जो आप कूद सकते हैं वह आखिरी निर्देश है। इसलिए यह नियम गारंटी देता है कि जब प्रोग्राम को "इंजन" प्रक्रिया में निष्पादित किया जाता है, तो कोई विसंगति नहीं होगी।

नियम C5 कहता है कि 32 बाइट्स से बड़े निर्देश नहीं हो सकते। हमने इस नियम के एक निश्चित संस्करण पर विचार किया जब हमने 32 बाइट्स में निर्देश आकारों की बहुलता के बारे में बात की, अन्यथा आप निर्देश के बीच में कूद सकते हैं और सिस्टम कॉल के साथ एक समस्या पैदा कर सकते हैं, जो वहां "छिपा" सकता है।

नियम C6 कहता है कि सभी उपलब्ध निर्देशों को शुरू से ही डिसाइड किया जा सकता है। इस प्रकार, यह सुनिश्चित करता है कि हम प्रत्येक निर्देश को देखते हैं और कार्यक्रम चलने पर सभी निर्देशों की जाँच कर सकते हैं।

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



श्रोता: C5 और C3 में क्या अंतर है?

प्रोफेसर: मुझे लगता है कि C5 कहता है कि अगर मेरे पास मल्टी-बाइट निर्देश है, तो यह आसन्न पतों की सीमाओं को पार नहीं कर सकता है। मान लीजिए कि मेरे पास निर्देशों की एक धारा है, और एक पता 32 है और एक पता 64 है। इसलिए, एक निर्देश 32 बाइट्स की सीमा को पार नहीं कर सकता है, अर्थात यह 64 से कम पते के साथ शुरू नहीं होना चाहिए और 64 से अधिक पते के साथ समाप्त होना चाहिए।



यह नियम C5 कहता है। क्योंकि अन्यथा, बहुलता 32 की छलांग लगाने के बाद, आप एक अन्य निर्देश के बीच में आ सकते हैं, जहां यह ज्ञात नहीं है कि क्या हो रहा है।

और नियम C3 कूद के किनारे पर इस निषेध का एक एनालॉग है। इसमें कहा गया है कि जब भी आप कूदते हैं, तो आपके कूदने की लंबाई 32 से अधिक होनी चाहिए।

C5 यह भी दावा करता है कि पता सीमा में कुछ भी जो कि 32 का गुणक है, एक सुरक्षित निर्देश है।

इन नियमों की सूची को पढ़ने के बाद, मेरे मन में एक मिश्रित भावना थी, क्योंकि मैं यह आकलन नहीं कर सका कि ये नियम पर्याप्त हैं, यानी सूची न्यूनतम या पूर्ण है।
तो, चलिए होमवर्क के बारे में सोचते हैं जिसे आपको पूरा करना है। मुझे लगता है कि वास्तव में सैंडबॉक्स में कुछ जटिल निर्देशों को निष्पादित करते समय मूल ग्राहक के संचालन में एक त्रुटि है। मेरा मानना ​​है कि उनके पास सही लंबाई कोडिंग नहीं थी, जिससे कुछ खराब हो सकता है, लेकिन मुझे याद नहीं है कि त्रुटि क्या थी।

मान लीजिए कि एक सैंडबॉक्स सत्यापनकर्ता गलत तरीके से किसी तरह के निर्देश की लंबाई प्राप्त करता है। इस मामले में क्या बुरा हो सकता है? आप इस पर्ची का उपयोग कैसे करेंगे?

श्रोता: उदाहरण के लिए, आप सिस्टम कॉल या रिटर्न स्टेटमेंट को छिपा सकते हैं।

प्रोफेसर: हाँ। मान लीजिए कि आपके द्वारा लिखे गए AND स्टेटमेंट का कुछ फैंसी संस्करण है। यह संभव है कि सत्यापनकर्ता से गलती हुई और माना गया कि इसकी लंबाई 5 बाइट्स की वास्तविक लंबाई के साथ 6 बाइट्स है।



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

इस प्रकार, मूल क्लाइंट सत्यापनकर्ता को सीपीयू के कार्यों के साथ अपने कार्यों को सिंक्रनाइज़ करना होगा, अर्थात, "अनुमान" बिल्कुल प्रोसेसर कैसे प्रत्येक निर्देश की व्याख्या करेगा। और यह सैंडबॉक्स के हर स्तर पर होना चाहिए, जिसे लागू करना काफी मुश्किल है।

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

तो अब हम कहाँ हैं? फिलहाल, हम समझते हैं कि सभी निर्देशों को कैसे अलग किया जाए और निषिद्ध निर्देशों के निष्पादन को कैसे रोका जाए। अब देखते हैं कि हम मूल क्लाइंट मॉड्यूल के भीतर कोड और डेटा दोनों के लिए मेमोरी और लिंक कैसे स्टोर करते हैं।

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

श्रोता: आप सभी उच्च बिट्स को साफ़ करने के लिए निर्देश लिख सकते हैं।



प्रोफेसर: हाँ, यह सही है। वास्तव में, हम देखते हैं कि हमारे पास यह निर्देश है और हर बार, उदाहरण के लिए, हम कहीं कूदते हैं, यह कम बिट्स को साफ करता है। लेकिन अगर हम कम से कम 256 एमबी के भीतर चलने वाले सभी संभावित कोड को रखना चाहते हैं, तो हम केवल पहली विशेषता च को 0 से बदल सकते हैं और $ 0xffffe0 के बजाय $ 0x0fffffe0 प्राप्त कर सकते हैं। यह कम बिट्स को साफ करता है और 256 एमबी की ऊपरी सीमा निर्धारित करता है।

इस प्रकार, यह वही करता है जो आप प्रदान करते हैं, यह सुनिश्चित करते हुए कि जब भी आप कूदते हैं, आप 256 एमबी के भीतर होते हैं। और तथ्य यह है कि हम डिससैम्ड कर रहे हैं यह भी सत्यापित करना संभव बनाता है कि सभी प्रत्यक्ष कूद पहुंच के भीतर हैं।

उनके कोड के लिए ऐसा नहीं करने का कारण यह है कि x86 प्लेटफॉर्म पर आप बहुत कुशलता से एन्कोड कर सकते हैं, जहां सभी ऊपरी बिट्स 1 हैं। इसका परिणाम AND और 3-बाइट अनुदेश के लिए 3-बाइट अनुदेश के अस्तित्व में है। कूदने के लिए। इस प्रकार, हमारे पास 3 बाइट्स का एक अतिरिक्त खर्च है। लेकिन अगर आपको गैर-यूनिट उच्च बिट की आवश्यकता है , तो च के बजाय इस 0 की तरह, तो आपको अचानक 5-बाइट निर्देश है। इसलिए, मुझे लगता है कि इस मामले में वे ओवरहेड के बारे में चिंतित हैं।

श्रोता: कुछ निर्देशों के अस्तित्व में कोई समस्या है जो उस संस्करण को बढ़ाते हैं जिसे आप प्राप्त करने की कोशिश कर रहे हैं? यही है, आप कह सकते हैं कि आपके निर्देश में लगातार पूर्वाग्रह या ऐसा कुछ हो सकता है?

प्रोफेसर: मुझे ऐसा लगता है। आप शायद निर्देशों को मना करेंगे जो कुछ जटिल पते के फार्मूले पर कूदते हैं और केवल उन निर्देशों का समर्थन करेंगे जो सीधे इस मूल्य पर कूदते हैं, और यह मान हमेशा प्राप्त होता है और ।

श्रोतागण: स्मृति की पहुँच के लिए यह अधिक आवश्यक है ...

प्रोफेसर: हाँ, क्योंकि यह सिर्फ कोड है। और x86 प्लेटफॉर्म पर मेमोरी एक्सेस करने के लिए, विशिष्ट मेमोरी लोकेशन तक पहुंचने के कई अजीब तरीके हैं। आमतौर पर, आपको पहले मेमोरी लोकेशन की गणना करनी होगी, फिर एक अतिरिक्त AND जोड़ना होगा , और उसके बाद ही एक्सेस करना होगा। मुझे लगता है कि इस टूलकिट के उपयोग के कारण प्रदर्शन में गिरावट के बारे में उनकी चिंता का असली कारण यह है।

X86 प्लेटफ़ॉर्म पर, या कम से कम लेख में वर्णित 32-बिट प्लेटफ़ॉर्म पर, वे कोड और एड्रेस डेटा को प्रतिबंधित मॉड्यूल का संदर्भ देने के बजाय हार्डवेयर समर्थन का उपयोग करते हैं।

आइए देखें कि सैंडबॉक्स में NaCl मॉड्यूल का उपयोग करने का तरीका जानने से पहले यह कैसा दिखता है। इस हार्डवेयर को विभाजन कहा जाता है। X86 प्लेटफ़ॉर्म पर स्वैप फ़ाइल मिलने से पहले ही यह उत्पन्न हो गया था। X86 प्लेटफ़ॉर्म पर, प्रक्रिया के दौरान एक समर्थित हार्डवेयर टेबल मौजूद है। हम इसे सेगमेंट डिस्क्रिप्टर की तालिका कहते हैं। यह किसी भी आकार की तालिका के अंत में 0 से लेकर खंडों का एक समूह है। यह यूनिक्स पर फ़ाइल डिस्क्रिप्टर की तरह कुछ है, सिवाय इसके कि प्रत्येक प्रविष्टि में 2 मान होते हैं: आधार आधार और लंबर लंबाई।

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



यह हमें x86 प्लेटफॉर्म पर मेमोरी की सीमाओं को बनाए रखने में मदद करता है, क्योंकि प्रत्येक निर्देश, मेमोरी तक पहुंच, इस तालिका में एक विशिष्ट सेगमेंट को संदर्भित करता है।

उदाहरण के लिए, जब हम mov (% eax), (% ebx) निष्पादित करते हैं, अर्थात, हम EAX रजिस्टर में संग्रहीत पॉइंटर से मेमोरी वैल्यू को EBX रजिस्टर में संग्रहीत किसी अन्य पॉइंटर में ले जाते हैं, तो प्रोग्राम को पता चलता है कि आरंभ और समाप्ति पते क्या हैं के मद्देनजर और दूसरे पते में मान को बचाएगा।

लेकिन वास्तव में, x86 प्लेटफ़ॉर्म पर, जब हम मेमोरी के बारे में बात करते हैं, तो एक अव्यवस्थित चीज़ होती है जिसे एक सेगमेंट डिस्क्रिप्टर कहा जाता है, जो यूनिक्स में एक फाइल डिस्क्रिप्टर के समान है। यह डिस्क्रिप्टर तालिका में सिर्फ एक सूचकांक है, और जब तक अन्यथा संकेत नहीं दिया जाता है, तब प्रत्येक ऑपरेशन कोड में एक डिफ़ॉल्ट खंड होता है।

इसलिए, जब आप mov (% eax) निष्पादित करते हैं, तो यह % ds या डेटा खंड रजिस्टर को संदर्भित करता है, जो आपके प्रोसेसर में एक विशेष रजिस्टर है। अगर मुझे सही से याद है, तो यह एक 16-बिट पूर्णांक है जो इस विवरण तालिका में इंगित करता है।

और वही (% ईबेक्स) के लिए जाता है - यह उसी % ds खंड चयनकर्ता को संदर्भित करता है। वास्तव में, x86 में हमारे पास 6 कोड चयनकर्ताओं का एक समूह है: CS, DS, ES, FS, GS और SS । सीएस कॉल चयनकर्ता को निर्देश प्राप्त करने के लिए निहित किया जाता है। इसलिए यदि आपका निर्देश सूचक कुछ को इंगित करता है, तो यह सीएस खंड चयनकर्ता को चुनने वाले को संदर्भित करता है।



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

यदि आपको कुछ पते तक पहुंच मिलती है, उदाहरण के लिए, चयनकर्ता % ds: addr में , हार्डवेयर इसे तालिका adrr + T [% ds] .base के साथ ऑपरेशन पर पुनर्निर्देशित करेगा। इसका मतलब है कि यह एक ही टेबल से मॉड्यूल की लंबाई का पता लेगा। इसलिए हर बार जब आप मेमोरी एक्सेस करते हैं, तो इसमें डिस्क्रिप्टर टेबल प्रविष्टियों के रूप में खंड चयनकर्ताओं का एक डेटाबेस होता है, और यह आपके द्वारा निर्दिष्ट पते को लेता है और संबंधित सेगमेंट की लंबाई के साथ मेल खाता है।

श्रोता: तो इसका उपयोग क्यों नहीं किया जाता है, उदाहरण के लिए, बफर की सुरक्षा के लिए?

प्रोफेसर: हाँ, यह एक अच्छा सवाल है! क्या हम बफर ओवरफ्लो से बचाने के लिए इसका उपयोग कर सकते हैं? उदाहरण के लिए, हमारे पास मौजूद प्रत्येक बफ़र के लिए, आप बफ़र बेस को यहां रख सकते हैं, और बफ़र आकार को।

श्रोता: क्या होगा अगर आपको इसे लिखने से पहले किसी तालिका में रखने की आवश्यकता नहीं है? आपको लगातार वहां रहने की आवश्यकता नहीं है।

प्रोफेसर: हाँ। इसलिए, मुझे लगता है कि इसका कारण यह है कि बफर ओवरफ्लो से बचाने के लिए इस दृष्टिकोण का उपयोग अक्सर नहीं किया जाता है क्योंकि इस तालिका में प्रविष्टियों की संख्या 16 डिग्री में 2 से अधिक नहीं हो सकती है, क्योंकि विवरणकर्ता 16 बिट लंबे होते हैं, लेकिन वास्तव में वास्तव में, कुछ और बिट्स का उपयोग अन्य चीजों के लिए किया जाता है। तो वास्तव में आप इस तालिका में रिकॉर्ड 13 वीं शक्ति में केवल 2 ही रख सकते हैं। इसलिए, यदि आपके पास अपने कोड में 2 ¹³ से बड़ा डेटा का एक सरणी है, तो इस तालिका का अतिप्रवाह हो सकता है।

इसके अलावा, कंपाइलर के लिए इस तालिका को सीधे प्रबंधित करना अजीब होगा, क्योंकि आमतौर पर सिस्टम कॉल का उपयोग करके हेरफेर किया जाता है। आप सीधे इस तालिका में नहीं लिख सकते, पहले आपको ऑपरेटिंग सिस्टम पर एक सिस्टम कॉल करने की आवश्यकता है, जिसके बाद ऑपरेटिंग सिस्टम इस तालिका में रिकॉर्ड रखेगा। इसलिए, मुझे लगता है कि अधिकांश कंपाइलर्स बस ऐसे जटिल मेमोरी बफर मैनेजमेंट सिस्टम से निपटना नहीं चाहेंगे।



वैसे, मल्टीएक्स इस दृष्टिकोण का उपयोग करता है: इसमें विभिन्न खंडों के लिए 2 ¹⁸ रिकॉर्ड और संभावित ऑफसेट के लिए 2 ¹⁸ रिकॉर्ड हैं। और प्रत्येक सामान्य पुस्तकालय का टुकड़ा या स्मृति खंड अलग-अलग खंड हैं। वे सभी रेंज के लिए जांचे जाते हैं और इसलिए उन्हें एक चर स्तर पर उपयोग नहीं किया जा सकता है।

श्रोता: संभवतः, कर्नेल का उपयोग करने की निरंतर आवश्यकता प्रक्रिया को धीमा कर देगी।

प्रोफेसर: हाँ, यह सही है। तो हम इस तथ्य के कारण ओवरहेड होंगे कि जब स्टैक पर अचानक एक नया बफर बनाया जाता है, तो हमें इसे जोड़ने के लिए एक सिस्टम कॉल करने की आवश्यकता होती है।

तो इनमें से कितने तत्व वास्तव में विभाजन तंत्र का उपयोग करते हैं? आप अनुमान लगा सकते हैं कि यह कैसे काम करता है। मुझे लगता है, डिफ़ॉल्ट रूप से, x86 में इन सभी खंडों का आधार 0 के बराबर है, और लंबाई 2 से 32 तक है। इस प्रकार, आप अपनी इच्छित पूरी मेमोरी तक पहुँच सकते हैं। इसलिए, NaCl के लिए, वे आधार 0 को एन्कोड करते हैं और लंबाई को 256 मेगाबाइट तक सेट करते हैं। फिर वे 256 एमबी क्षेत्र के लिए इस रिकॉर्ड में 6 खंड चयनकर्ताओं के सभी रजिस्टरों की ओर इशारा करते हैं। इस प्रकार, जब भी उपकरण मेमोरी तक पहुंचता है, तो वह इसे 256 एमबी की ऑफसेट के साथ संशोधित करता है। इसलिए मॉड्यूल को बदलने की क्षमता 256 एमबी तक सीमित होगी।

मुझे लगता है कि अब आप समझ गए हैं कि यह हार्डवेयर कैसे समर्थित है और यह कैसे काम करता है, इसलिए आप इन सेगमेंट चयनकर्ताओं का उपयोग कर सकते हैं।
तो अगर हम इस योजना को लागू करते हैं तो क्या गलत हो सकता है? क्या हम एक अविश्वसनीय मॉड्यूल में खंड चयनकर्ता से बाहर कूद सकते हैं? मुझे लगता है कि इससे सावधान रहने वाली एक बात यह है कि ये रजिस्टर नियमित रजिस्टर की तरह होते हैं, और आप उनमें से मूल्यों को बाहर और बाहर स्थानांतरित कर सकते हैं। इसलिए, आपको यह सुनिश्चित करना चाहिए कि अविश्वासित मॉड्यूल इन सेगमेंट चयनकर्ताओं को विकृत नहीं करता है। क्योंकि डिस्क्रिप्टर टेबल में कहीं भी एक रिकॉर्ड हो सकता है, जो कि एक प्रक्रिया के लिए स्रोत सेगमेंट डिस्क्रिप्टर भी है जिसका आधार 0 है और 2 ³² तक की लंबाई है।



इसलिए यदि कोई अविश्वसनीय मॉड्यूल सीएस , या डीएस , या ईएस , या इनमें से किसी भी चयनकर्ता को बदलने में सक्षम था, ताकि वे इस मूल ऑपरेटिंग सिस्टम को इंगित करना शुरू कर दें, जो आपके सभी एड्रेस स्पेस को कवर करता है, तो आप इस सेगमेंट में मेमोरी लिंक बना सकते हैं " सैंडबॉक्स से बाहर कूदें।

इस प्रकार, मूल ग्राहक को इस निषिद्ध सूची में कुछ और निर्देश जोड़ने थे। मुझे लगता है कि वे सभी निर्देशों की तरह मना करते हैं जैसे कि mov% ds, es इत्यादि। इसलिए, सैंडबॉक्स में एक बार, आप उस सेगमेंट को नहीं बदल सकते हैं जिसमें कुछ चीजें संदर्भित हैं। X86 प्लेटफ़ॉर्म पर , सेगमेंट डिस्क्रिप्टर टेबल को बदलने के निर्देश विशेषाधिकार प्राप्त हैं, लेकिन डीएस को बदलना , स्वयं को बदलना , आदि। तालिका पूरी तरह से अनपेक्षित है।

श्रोता: क्या आप टेबल को इनिशियलाइज़ कर सकते हैं ताकि सभी अप्रयुक्त स्लॉट में शून्य लंबाई रखी जाए?

प्रोफेसर: हाँ। आप किसी ऐसी चीज के लिए तालिका की लंबाई निर्धारित कर सकते हैं जहां कोई अप्रयुक्त स्लॉट नहीं हैं। यह पता चला है कि आपको वास्तव में 0 और 2 ³² वाले इस अतिरिक्त स्लॉट की आवश्यकता है, क्योंकि विश्वसनीय रनटाइम वातावरण इस सेगमेंट में शुरू होना चाहिए और संपूर्ण मेमोरी रेंज तक पहुंच प्राप्त करना चाहिए। तो काम करने के लिए विश्वसनीय रनटाइम वातावरण के लिए यह प्रविष्टि आवश्यक है।

श्रोता: तालिका के आउटपुट की लंबाई को बदलने के लिए क्या आवश्यक है?
प्रोफेसर: आपके पास रूट विशेषाधिकार होना चाहिए। लिनक्स में वास्तव में स्थानीय डिस्क्रिप्टर टेबल के लिए एक सिस्टम है जिसे Rev_ldt () कहा जाता है, जो किसी भी प्रक्रिया को अपनी स्वयं की तालिका को संशोधित करने की अनुमति देता है, अर्थात प्रत्येक प्रक्रिया के लिए वास्तव में एक तालिका होती है। लेकिन x86 प्लेटफॉर्म पर यह अधिक जटिल है, एक वैश्विक तालिका और एक स्थानीय तालिका दोनों है। एक विशिष्ट प्रक्रिया के लिए एक स्थानीय तालिका को बदला जा सकता है।

अब आइए यह पता लगाने की कोशिश करें कि हम मूल ग्राहक निष्पादन प्रक्रिया से कैसे कूदते और कूदते हैं या सैंडबॉक्स से बाहर कूदते हैं। हमारे बाहर कूदने का क्या मतलब है?



इसलिए, हमें इस विश्वसनीय कोड को चलाने की आवश्यकता है, और यह विश्वसनीय कोड 256 एमबी सीमा से ऊपर कहीं "जीवन" है। वहां कूदने के लिए, हमें उन सभी सुरक्षाओं को पूर्ववत करना होगा जो मूल ग्राहक ने स्थापित की हैं। मूल रूप से वे इन छह चयनकर्ताओं को बदलने के लिए उतरते हैं। मुझे लगता है कि हमारा सत्यापनकर्ता 256 एमबी सीमा से ऊपर स्थित चीजों के लिए समान नियम लागू नहीं करने जा रहा है, इसलिए यह काफी सरल है।

लेकिन फिर हमें किसी तरह विश्वसनीय रनटाइम रन में कूदने की जरूरत है और इस विशाल खंड के लिए खंड चयनकर्ताओं को सही मानों को फिर से स्थापित करना है, पूरी प्रक्रिया के पते की जगह को कवर करना है - यह सीमा 0 से 2 ^{32 तक है} । उन्होंने इस तरह के तंत्र को मूल ग्राहक "ट्रम्पोलिन" ट्रम्पोलिन और "स्प्रिंगबोर्ड" स्प्रिंगबोर्ड में विद्यमान कहा। वे कम 64k मॉड्यूल में रहते हैं। सबसे अच्छी बात यह है कि ये "ट्रैम्पोलाइन" और "जंप" कोड के टुकड़े प्रक्रिया के निचले 64k में पड़े हैं। इसका मतलब है कि यह अविश्वसनीय मॉड्यूल वहां कूद सकता है, क्योंकि यह एक वैध कोड पता है जो 32 बिट्स की सीमा के भीतर और 256 एमबी के भीतर है। तो आप इस trampoline पर कूद सकते हैं।

Native Client «» - . , Native Client «», trampoline trusted runtime . , DS, CS , .

, , - malo , «», «» 32- .

, 4096 + 32 , . , , mov %ds, 7 , ds , 7 0 2 ³² . CS trusted service runtime , 256 .



, , , trusted service runtime , . , . DS , , , , - .

, ? , «»? , ?

: 64.

: , , . malo, 64, 32 . , , , .

, 32- , . , , 32 , 32- , . «» trusted runtime 32 .



. , , DS, CS . , 256- , trusted runtime , . .

«», trusted runtime 256 Native Client . «» DS , , mov %ds, 7 , , trusted runtime . . , «», - .

halt 32- «». «», . trusted service runtime , 1 .



trusted service runtime , , .

: «» ?

: «» 0 256 . 64- , , «», - -. Native Client .

: ?

: , ? , «»? ?

: , ?

: , - %eax , trusted runtime : «, »! EAX , mov , «» EAX , trusted runtime . , «»?

: , , . …

: , , — , , 0 2 ³² . . «», 256 .

, «», . , «» , . , «» .

: «» 256 ?

: , . , CS - . «», halt , mov, CS , , 256 .

, , «». , DS , , CSऔर कहीं कूदो।

शायद, अगर आपने कोशिश की, तो आप x86 निर्देशों के कुछ अनुक्रम के साथ आ सकते हैं जो मूल क्लाइंट मॉड्यूल के पता स्थान की सीमाओं के बाहर ऐसा कर सकते हैं ।

इसलिए, आपको अगले सप्ताह देखें और वेब सुरक्षा के बारे में बात करें।


पाठ्यक्रम का पूरा संस्करण यहां उपलब्ध है ।

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

VPS (KVM) E5-2650 v4 (6 करोड़) 10GB DDR4 240GB SSD 1Gbps दिसंबर तक मुफ्त में जब छह महीने की अवधि के लिए भुगतान करते हैं, तो आप यहां ऑर्डर कर सकते हैं ।

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 टीवी 249 डॉलर में नीदरलैंड और यूएसए से है! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?