एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 2: "हैकर हमलों का नियंत्रण", भाग 1

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

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

व्याख्यान 1: "परिचय: खतरे के मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 2: "हैकर हमलों का नियंत्रण" भाग 1 / भाग 2 / भाग 3

जेम्स मिकेंस: पिछले व्याख्यान से, हमने बफर ओवरफ़्लो हमलों के बारे में सब सीखा, और आज हम इन हमलों को लॉन्च करने के कुछ तरीकों पर चर्चा करना जारी रखेंगे। बफर अतिप्रवाह हमले के पीछे मूल विचार इस प्रकार है।



सबसे पहले, मैं ध्यान देता हूं कि ये हमले कई अलग-अलग परिस्थितियों को प्रभावित करते हैं। पहली परिस्थिति जो वे उपयोग करते हैं वह यह है कि सिस्टम सॉफ्टवेयर अक्सर सी में लिखा जाता है।

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

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

इसके अलावा, बफर अतिप्रवाह हमले वास्तुकला के x86 ज्ञान का उपयोग करते हैं, उदाहरण के लिए, जिस दिशा में स्टैक बढ़ रहा है। कार्यों के लिए एक कॉलिंग सम्मेलन क्या है? जब आप फ़ंक्शन सी तक पहुंचते हैं, तो स्टैक कैसा दिखता है? और जब आप ढेर पर एक वस्तु का चयन करते हैं, तो ये मुख्य चयनित संरचनाएं क्या दिखती हैं?

आइए एक साधारण उदाहरण देखें। यह वही है जो आपने पिछले व्याख्यान में देखा था। तो, यहाँ हमारे पास एक मानक रीड रिक्वेस्ट है, और फिर हमें एक बफर मिलता है, यहाँ, फिर कैनोनिकल int i आता है, उसके बाद बदनाम को कमांड मिलती है । और नीचे हमारे पास अन्य आवश्यक चीजें हैं।



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

बहुत नीचे की तरफ सरणी "i" है। इसके ऊपर एक बफ़र स्थित है, इसमें सबसे नीचे पहला पता है, और सबसे ऊपर आखिरी है। किसी भी मामले में, बफर के ऊपर हमारे पास गैप इंडिकेटर का बचाया मूल्य है - बचाया मूल्य EBP। ऊपर यह फ़ंक्शन के लिए वापसी पता है, और इससे भी उच्च पिछले फ्रेम से कुछ चीजें हैं।

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



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

इसका फायदा उठाने के लिए एक हमलावर क्या करता है? मूल रूप से, यह डेटा के लंबे अनुक्रम में प्रवेश करता है। इसलिए, महत्वपूर्ण विचार यह है कि इस तरह की तकनीक का इस्तेमाल हमला करने के लिए किया जा सकता है।

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

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

एक ऐसी बात है जिसके बारे में आपको सोचना होगा और एक छात्र के रूप में मैंने सोचा:

"महान, उन्होंने हमें दिखाया कि कैसे बफर ओवरफ्लो करना है, लेकिन ऑपरेटिंग सिस्टम इसे क्यों नहीं रोक सकता है? क्या वह आकाशगंगा के रखवालों की तरह किसी के रूप में कार्य करता है, जो चारों ओर हो रही बुरी चीजों से अच्छे की रक्षा करता है? "

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

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

यह एक बफर अतिप्रवाह कैसे दिखता है। हम इन सब चीजों को कैसे ठीक करने जा रहे हैं?

बफर ओवरफ्लो को रोकने का एक तरीका यह है कि सी कोड में त्रुटियों से बचें। यह एक रचनात्मक दृष्टिकोण है, क्योंकि यदि आपके प्रोग्राम में कोई त्रुटि नहीं है, तो हमलावर उनका उपयोग नहीं कर सकता है। हालाँकि, यह कहा से आसान है। कुछ बहुत ही सरल चीजें हैं जो प्रोग्रामर सुरक्षा के "स्वच्छता" प्रदान करने के लिए कर सकते हैं। उदाहरण के लिए, जैसी सुविधाएँ मिलती हैं, जिन्हें अब हम जानते हैं कि उन्हें "गो-टू," या "ऑपरेटिंग सिस्टम पर कब्जा" कहा जा सकता है, जो एक सुरक्षा उल्लंघन है।

इसलिए, जब आप GCC या Visual Studio जैसे आधुनिक संकलक का उपयोग करके अपने कोड को संकलित करते हैं, तो वे ऐसे कार्यों के नुकसान का संकेत देंगे। वे कहेंगे: "अरे, आप एक खतरनाक चीज का उपयोग कर रहे हैं, बेहतर है कि फंक्शन फ़ंक्शन या अन्य कार्यों का उपयोग करें जो वास्तव में सीमा अनुपालन को बनाए रख सकते हैं।" यह उन साधारण चीजों में से एक है जो प्रोग्रामर कर सकते हैं।

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

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

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



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

कल्पना करें कि आपके पास ऐसा कोई फ़ंक्शन है, चलो इसे शून्य फू (इंट, * पी) कहते हैं , इसमें पूर्णांक डेटा और एक पॉइंटर शामिल हैं। मान लें कि यह पूर्णांक ऑफ़सेट मान को बंद घोषित करता है । यह फ़ंक्शन एक अन्य पॉइंटर की घोषणा करता है और इसमें एक ऑफसेट जोड़ता है: int * z = p + off । अब भी, एक फ़ंक्शन लिखते समय, स्थैतिक कोड विश्लेषण हमें बता सकता है कि यह ऑफ़सेट वेरिएबल इनिशियलाइज़ नहीं है।



इस प्रकार, कार्यक्रम का विश्लेषण करके, इस सवाल का जवाब देना संभव है कि क्या हमारा कार्य ठीक से काम करेगा। और इस उदाहरण में, यह बहुत सरल है कि उत्तर "नहीं, यह नहीं है" क्योंकि कोई ऑफ़सेट इनिशियलाइज़ेशन नहीं है। स्टेटिक विश्लेषण सॉफ्टवेयर है, और जैसा कि आप अपने कोड को बनाने के लिए लोकप्रिय संकलक का उपयोग करते हैं, यह आपको बताएगा: “अरे, दोस्त, यह बात प्रारंभिक नहीं है। क्या आप वाकई ऐसा करना चाहते हैं? " स्थैतिक विश्लेषण का उपयोग करने का यह सबसे सरल उदाहरणों में से एक है।

एक अन्य उदाहरण उस मामले पर विचार करता है जब हमारे पास एक फ़ंक्शन की शाखा होती है, अर्थात, एक निश्चित स्थिति के तहत इसका निष्पादन।



इसलिए, यदि ऑफ़सेट 8 से अधिक है, यदि (ऑफ> 8) , तो यह कुछ फ़ंक्शन बार (ऑफ) को कॉल करता है। तो, यह स्थिति हमें बताती है कि ऑफसेट मूल्य क्या है। यहां तक ​​कि इस तथ्य की अनदेखी करते हुए कि फ़ंक्शन की इस शाखा का विश्लेषण करते समय, ऑफसेट को प्रारंभ नहीं किया जाता है, हम अभी भी पता लगाते हैं कि यह 8. से अधिक हो सकता है। इसलिए, जब हम बार का स्थैतिक विश्लेषण करना शुरू करते हैं, तो हमें पता चलता है कि ऑफसेट केवल कुछ मान ले सकते हैं। मैं एक बार फिर ध्यान देता हूं कि यह स्थैतिक विश्लेषण का एक बहुत ही सतही परिचय है, बाद में हम इस उपकरण पर अधिक विस्तार से विचार करेंगे। लेकिन यह उदाहरण दिखाता है कि आप कोड को निष्पादित किए बिना भी कुछ प्रकार की त्रुटियों का पता कैसे लगा सकते हैं।

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

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



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

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

इसके कई कारण हैं। सबसे पहले, इन भाषाओं में सी से विरासत में मिले कोड के कई तत्व हैं। यदि आप एक नई परियोजना शुरू करते हैं और इसके लिए स्मृति सुरक्षा सुनिश्चित करते हैं, तो आप उच्च स्तरीय भाषाओं में से एक का उपयोग करते हैं। लेकिन क्या होगा अगर आपको एक बड़ी बाइनरी फ़ाइल या एक बड़ा स्रोत वितरण दिया गया था जो सी में लिखा गया था और 10-15 वर्षों तक बनाए रखा गया था, यह एक पीढ़ीगत परियोजना थी, मेरा मतलब है कि हमारे बच्चे भी इस पर काम करना जारी रखेंगे ? इस मामले में, आप यह नहीं कह पाएंगे: "मैं इसे C # में फिर से लिखता हूं और दुनिया को बदल देता हूं।"

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

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

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



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

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

इसके अलावा, सी का उपयोग करने की आवश्यकता तब उत्पन्न होती है जब आप सिस्टम प्रदर्शन के बारे में चिंतित होते हैं। , , , . , , . , , memory-safe . , JIT. , Java, Java Script. , , «». , . , «» x86.

, , -. , , JVM, - Java. , - . , - JVM , . , , . . , , .

, , 86. JIT- , . JIT- , .

, JavaScript , , «» 32- , . JIT-, «» . , , JIT-, , , .



«» , asm.js – JavaScript, , , . , , , JavaScript , . JavaScript, JavaScript, C ++.

, -, IO. . , , , , . «» , .

. , - . , C C++, , . Python, , , . . .

, , , .

, . , . , . , «» , . , C C++, .

, ? , , ? ?

. , – . , - , . , . , -, , . IP , , . , - . , , . , , «» .

, , , , , , . , - , . , , , . , , , , , , .



, . stack canaries, « », , . « » , , , . , , .

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

28:30 मिनट

निरंतरता:

एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 2: "हैकर हमलों का नियंत्रण", भाग 2


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

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

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