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

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 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

श्रोता: पता सीमा स्मृति क्षमता रेंज खरोंच से क्यों शुरू होनी चाहिए?

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

श्रोता: मुझे लगा कि मास्क लगाना संरेखण प्रदान करना था।

प्रोफेसर: ठीक है, मुखौटा संरेखण प्रदान करता है, लेकिन यह खरोंच से क्यों शुरू होता है? मुझे लगता है कि वे सेगमेंटेशन हार्डवेयर सेगमेंटेड हार्डवेयर पर भरोसा करते हैं। तो मूल रूप से, वे इसका उपयोग रैखिक स्थान के संदर्भ में क्षेत्र को ऊपर ले जाने के लिए कर सकते हैं। या शायद यह सिर्फ इस सीमा से संबंधित है कि कैसे आवेदन "इस सीमा को देखता है"। वास्तव में, आप इसे अपने वर्चुअल एड्रेस स्पेस में अलग-अलग स्थानों पर रख सकते हैं। इससे आप एक ही एड्रेस स्पेस में मल्टीपल मॉड्यूल चलाने के लिए सेगमेंटेड हार्डवेयर के साथ कुछ ट्रिक्स कर पाएंगे।



श्रोता: शायद ऐसा इसलिए है क्योंकि वे अशक्त पॉइंटर के "पॉइंट" को पकड़ना चाहते हैं?

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

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

इसलिए, हम मुख्य प्रश्न जारी रखते हैं - सुरक्षा के दृष्टिकोण से हम क्या सुनिश्चित करना चाहते हैं। आइए इस मामले को कुछ हद तक "भोलेपन" से देखें और देखें कि हम कैसे सब कुछ बर्बाद कर सकते हैं, और फिर इसे ठीक करने का प्रयास करें।

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



इस पंक्ति में पहले NOP निर्देश मॉड्यूल, फिर ADD अनुदेश मॉड्यूल, NOT , JUMP और इसी तरह हो सकता है। आप बस खोज करते हैं, और यदि आप एक बुरा निर्देश पाते हैं, तो कहें कि यह एक खराब मॉड्यूल है और इसे छोड़ दें। और अगर आपको इस निर्देश के लिए कोई सिस्टम कॉल नहीं दिखता है, तो आप इस मॉड्यूल के लॉन्च को सक्षम कर सकते हैं और 0-256 की सीमा के भीतर सब कुछ कर सकते हैं। आपको लगता है कि यह काम करेगा या नहीं? वे किस बारे में चिंतित हैं? यह इतना कठिन क्यों है?

श्रोता: क्या वे निर्देशों के आकार के बारे में चिंतित हैं?

प्रोफेसर: हाँ, तथ्य यह है कि x86 प्लेटफ़ॉर्म में चर-लंबाई निर्देश हैं। इसका मतलब है कि निर्देश का सटीक आकार इस निर्देश के पहले कुछ बाइट्स पर निर्भर करता है। वास्तव में, आप यह कहने के लिए पहले बाइट को देख सकते हैं कि निर्देश बहुत बड़ा होगा, और फिर आपको कुछ और बाइट्स को देखना पड़ सकता है, और फिर यह तय करें कि यह किस आकार का है। स्पार्क , एआरएम , एमआइपी जैसे कुछ आर्किटेक्चर के पास अधिक निश्चित लंबाई के निर्देश हैं। एआरएम में दो निर्देश लंबाई है - या तो 2 या 4 बाइट्स। लेकिन x86 प्लेटफ़ॉर्म पर , निर्देशों की लंबाई 1, 5 और 10 बाइट्स हो सकती है, और यदि आप कोशिश करते हैं, तो आप 15 बाइट्स का एक लंबा निर्देश भी प्राप्त कर सकते हैं। हालांकि, ये जटिल निर्देश हैं।

नतीजतन, एक समस्या दिखाई दे सकती है। यदि आप कोड की इस लाइन को रैखिक रूप से स्कैन करते हैं, तो सब कुछ ठीक हो जाएगा। लेकिन हो सकता है कि रनटाइम के दौरान आप किसी तरह के निर्देश के बीच में पहुंच जाएंगे, उदाहरण के लिए, नहीं ।



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

एक और उदाहरण जिसमें हम असेंबलर के साथ "खेलेंगे"। मान लीजिए हमारे पास 25 सीडी 80 00 00 है । 2 बाइट को देखने के बाद, आप इसे पांच-बाइट अनुदेश के रूप में व्याख्या करेंगे, अर्थात, आपको 5 बाइट्स को आगे देखना होगा और यह देखना होगा कि यह ANDAX EAX निर्देश , 0x00 00 80 सीडी के साथ है, और कुछ के साथ EAX रजिस्टर के लिए ऑपरेटर शुरू करें परिभाषित स्थिरांक, उदाहरण के लिए, 00 00 80 सीडी । यह सुरक्षित निर्देशों में से एक है जो मूल ग्राहक को केवल द्विआधारी निर्देशों की जांच के पहले नियम से अनुमति देना चाहिए। लेकिन अगर, प्रोग्राम के निष्पादन के दौरान, सीपीयू यह तय करता है कि उसे सीडी से कोड को निष्पादित करना शुरू करना चाहिए, तो मैं निर्देश के इस स्थान को एक तीर से चिह्नित करूंगा, फिर अनुदेश % EAX, 0x00 00 80 सीडी , जो वास्तव में एक 4-बाइट अनुदेश है, का अर्थ होगा INT का निष्पादन $ 0x80 , जो कि लिनक्स पर सिस्टम कॉल करने का एक तरीका है।



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

शायद हमें प्रत्येक बाइट के ऑफसेट को देखने की कोशिश करनी चाहिए। क्योंकि x86 केवल बाइट में एक निर्देश की व्याख्या शुरू कर सकता है, बिट नहीं, सीमाएं। इस प्रकार, आपको निर्देश देखने के लिए प्रत्येक बाइट की ऑफसेट को देखना होगा जहां निर्देश शुरू होता है। क्या आपको लगता है कि यह एक व्यवहार्य योजना है?

श्रोता: मुझे लगता है कि अगर कोई वास्तव में और का उपयोग करता है, तो प्रोसेसर इस जगह पर नहीं जाएगा, लेकिन बस प्रोग्राम को चलने दें।

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

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

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

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



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

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

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

एकमात्र समस्या यह है कि आप कार्यक्रम में प्रत्येक कूद के लक्ष्यों की जांच नहीं कर सकते, क्योंकि अप्रत्यक्ष कूद हो सकते हैं। उदाहरण के लिए, x86 में आपके पास इस EAX रजिस्टर के मूल्य के लिए एक छलांग जैसा कुछ हो सकता है। यह फ़ंक्शन पॉइंटर्स को लागू करने के लिए बहुत अच्छा है।



यही है, फ़ंक्शन पॉइंटर मेमोरी में कहीं है, आप इसे कुछ रजिस्टर में रखते हैं, और फिर आंदोलन रजिस्टर में किसी भी पते पर जाते हैं।

तो कैसे इन लोगों को अप्रत्यक्ष कूद के साथ सामना करते हैं? क्योंकि, वास्तव में, मुझे पता नहीं है कि क्या यह बाइट सीडी या 25 बाइट के लिए एक "कूद" होगा। वे इस मामले में क्या करते हैं?

श्रोता: टूल्स का उपयोग कर रहे हैं?

प्रोफेसर: हाँ, इंस्ट्रूमेंटेशन उनकी मुख्य चाल है। इसलिए, जब भी वे देखते हैं कि संकलक पीढ़ी तैयार करने के लिए तैयार है, तो यह इस बात का प्रमाण है कि इस कूद से परेशानी नहीं होगी। ऐसा करने के लिए, उन्हें यह सुनिश्चित करने की आवश्यकता है कि सभी कूदता 32 बाइट्स की बहुलता के साथ किया जाता है। वे इसे कैसे करते हैं? वे सभी छलांग निर्देश बदलते हैं जिसे उन्होंने "छद्म निर्देश" कहा है। ये वही निर्देश हैं, लेकिन उपसर्ग हैं, जो EAX रजिस्टर में 5 कम बिट्स को साफ करता है। तथ्य यह है कि निर्देश 5 कम बिट्स को साफ करता है इसका मतलब है कि यह दिए गए मूल्य को 32 के गुणक का कारण बनता है, दो से पांच तक, और फिर इस मूल्य में एक छलांग पहले से ही लगाई जाती है।



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

इस प्रकार, इस टूलकिट के अलावा, आप सत्यापित करते हैं कि प्रत्येक कोड जो कि 32 का गुणक है, सही निर्देश है। एक वैध, मान्य निर्देश से मेरा आशय एक ऐसे निर्देश से है जो बाएं से दाएं से जुड़ा हुआ है।

श्रोता: संख्या ३२ को क्यों चुना गया है?

प्रोफेसर: हाँ, उन्होंने 1000 या 5 के बजाय 32 क्यों चुना? 5 खराब क्यों है?

श्रोता: क्योंकि संख्या २ की शक्ति होनी चाहिए।

प्रोफेसर: हाँ, ठीक है, ऐसा क्यों है। क्योंकि अन्यथा, 5 के एक से अधिक के उपयोग को सुनिश्चित करने के लिए अतिरिक्त निर्देशों के लिए ओवरहेड की आवश्यकता होगी। आठ के बारे में क्या? आठ एक अच्छी संख्या है?

श्रोता: आपके पास आठ बिट्स से अधिक लंबे निर्देश हो सकते हैं।

प्रोफेसर: हाँ, यह x86 प्लेटफ़ॉर्म पर अनुमत सबसे लंबे निर्देश के लिए हो सकता है। यदि हमारे पास 10-बाइट का निर्देश है, और सब कुछ 8 का गुणक होना चाहिए, तो हम इसे कहीं भी सम्मिलित नहीं कर सकते। तो लंबाई सभी मामलों के लिए पर्याप्त होनी चाहिए, क्योंकि मैंने जो सबसे बड़ा निर्देश देखा वह 15 बाइट्स लंबा था। तो 32 बाइट्स पर्याप्त हैं।

यदि आप प्रक्रिया सेवा वातावरण में प्रवेश करने या बाहर निकलने के लिए निर्देशों को अनुकूलित करना चाहते हैं, तो आपको एक 32-बाइट स्लॉट में कोड की कुछ nontrivial राशि की आवश्यकता हो सकती है। उदाहरण के लिए, 31 बाइट्स, क्योंकि 1 बाइट में एक निर्देश होता है। क्या यह बहुत बड़ा होना चाहिए? क्या हमें इसे 1024 बाइट्स के बराबर बनाना चाहिए? यदि आपके पास कई फ़ंक्शन पॉइंटर्स या कई अप्रत्यक्ष जंप हैं, तो हर बार जब आप कुछ जगह बनाना चाहते हैं, जहां आप कूदने जा रहे हैं, तो आपको इसकी कीमत की परवाह किए बिना इसे अगली सीमा तक जारी रखना चाहिए। तो 32 बिट्स के साथ यह काफी सामान्य आकार है। सबसे खराब स्थिति में, आप केवल 31 बाइट्स खो देंगे यदि आपको अगली सीमा पर जल्दी से जाने की आवश्यकता है। लेकिन अगर आपके पास एक आकार है जो कि 1024 बाइट्स का एक से अधिक है, तो एक अप्रत्यक्ष छलांग के लिए व्यर्थ में स्मृति के एक पूरे किलोबाइट को बर्बाद करने की संभावना है। यदि आपके पास छोटे फ़ंक्शन या कई फ़ंक्शन पॉइंटर्स हैं, तो "कूद" की लंबाई की बहुलता का इतना बड़ा आकार स्मृति के महत्वपूर्ण अपशिष्ट का कारण होगा।

मुझे नहीं लगता कि 32 नंबर मूल निवासी क्लाइंट के लिए ठोकर है। कुछ ब्लॉक 16 बिट्स, 64 या 128 बिट्स की बहुलता के साथ काम कर सकते हैं, इससे कोई फर्क नहीं पड़ता। बस 32 बिट्स उन्हें सबसे स्वीकार्य, इष्टतम मूल्य लग रहे थे।

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



इसलिए, जब भी वह कूदता है, जैसा कि शीर्ष पंक्ति में दिखाया गया है, तो उसे नीचे की 2 पंक्तियों में दिए गए इन अतिरिक्त निर्देशों को जोड़ना होगा। और इस तथ्य की परवाह किए बिना कि वह एक फ़ंक्शन बनाता है जिसे वह "कूद" जाएगा, हमारा निर्देश इसके अतिरिक्त और $ 0xffffffe0 के रूप में कूद जाएगा ,% eax इंगित करता है। और यह सिर्फ शून्य के साथ इसे पूरक नहीं कर सकता है, क्योंकि यह सब सही कोड होना चाहिए। इस प्रकार, यह सुनिश्चित करने के लिए आवश्यक है कि हर संभव निर्देश मान्य हो। और, सौभाग्य से, x86 प्लेटफॉर्म पर, एक भी बाइट फ़ंक्शन को एक एकल बाइट द्वारा वर्णित नहीं किया गया है, या कम से कम आकार में एक भी 1 बाइट नहीं है। इस प्रकार, आप हमेशा चीजों को एक स्थिर मूल्य में जोड़ सकते हैं।

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

श्रोता: यह स्टैक को ओवरफ्लो कर सकता है।

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

श्रोता: रुको, लेकिन आप स्टैक पर कुछ भी डाल सकते हैं। और जब आप एक अप्रत्यक्ष कूद लेते हैं।

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

श्रोता: क्या यह उसी सीमा तक कूदने पर लागू नहीं होता है?

प्रोफेसर: हाँ, तो वहाँ एक छलांग के साथ क्या होता है? क्या हमारी दौड़ की स्थितियां किसी भी तरह इस परीक्षा को अमान्य कर सकती हैं?

श्रोता: लेकिन क्या कोड लिखने योग्य नहीं है?

प्रोफेसर: हाँ, कोड नहीं लिखा जा सकता, यह सच है। इसलिए, आप संशोधित और नहीं कर सकते। लेकिन क्या इन दो निर्देशों के बीच कुछ अन्य धारा कूदने के उद्देश्य को नहीं बदल सकती है?

श्रोता: यह रजिस्टर में है, इसलिए…

प्रोफेसर: हाँ, यह एक अच्छी बात है। क्योंकि यदि कोई स्ट्रीम मेमोरी में या जो EAX से लोड की गई है (निश्चित रूप से, आप इसे डाउनलोड करने से पहले करते हैं), तो इस मामले में यह EAX खराब स्थिति में होगा, लेकिन तब यह खराब बिट्स को साफ कर देगा। या वह मेमोरी को तब बदल सकता है, जब पॉइंटर पहले से ही EAX में हो , तो इससे कोई फर्क नहीं पड़ता कि यह मेमोरी का स्थान बदल देता है जिससे EAX रजिस्टर लोड किया गया था।

वास्तव में, थ्रेड्स रजिस्टर सेट साझा नहीं करते हैं। इसलिए, यदि कोई अन्य थ्रेड EAX रजिस्टर को बदलता है, तो यह इस थ्रेड के EAX रजिस्टर को प्रभावित नहीं करेगा। इसलिए, अन्य थ्रेड्स निर्देशों के इस क्रम को अमान्य नहीं कर सकते।

एक और दिलचस्प सवाल है। हम इस के आसपास प्राप्त कर सकते हैं और ? मैं इस पते की जगह में कहीं भी जा सकता हूं। , AND .



, , , , , AND . . jmp , .



, , - , 1237. , 32. Native Client , , , . , , 1237 ?



- EAX , , , , . , ? ?

: NaCl , .

: , . x86 , , NaCl , 2 . , , : «, , !», 25 CD 80 00 00 . . , x86 .

, Native Client . , , , , NaCl . , .

: , , . , . , , , , .



: , . , . , , , EAX . , - . EAX , EBX . , . EAX EBX AND . , , EAX , . , - 64 . Jmp *% eax AND .



, , , , . Intel , , , , . , , . AND , EAX , «» .

, , . , . , , , . , , , .
, , C1 C7 .

C1 , , . , «» . , , . , , - . , .
2 , 0 64 . , , . , , .

3 , , , . , , .

4 , hlt . halt ? , C4 . , , - , .

, , ? , , - .
, , , , . , , , , . .



55:20

:

एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। 7: « Native Client», 3


.

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

3 Dell R630 — 2 Intel Deca-Core Xeon E5-2630 v4 / 128GB DDR4 / 41TB HDD 2240GB SSD / 1Gbps 10 TB — $99,33 , , .

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