बफर ओवरफ्लो: Difference between revisions
No edit summary |
No edit summary |
||
| Line 113: | Line 113: | ||
इस तकनीक की लोकप्रियता के कारण बहुत से घुसपैठियों द्वारा रोकथाम के लिए इस पद्धति में से कई विक्रेता काम में इस्तेमाल होने वाले शेलकोड का पता लगाने के प्रयास में मशीन से नो-ऑप सिस्टम के निर्देशों की खोज करेंगे। यह ध्यान रखना महत्वपूर्ण है कि एनओपी-स्लेज में केवल पारंपरिक नो-ऑप मशीन निर्देश ही शामिल नहीं हैं; कोई भी निर्देश जो मशीन की स्थिति को उस बिंदु तक दूषित नहीं करता है जहां शेलकोड नहीं चलेगा, हार्डवेयर की सहायता से नो-ऑप के स्थान पर उपयोग किया जा सकता है। नतीजतन, शोषण करने वाले लेखकों के लिए बेतरतीब ढंग से चुने गए निर्देशों के साथ नो-ऑप स्लेज की रचना करना आम बात हो गई है, जिसका शेलकोड निष्पादन पर कोई वास्तविक प्रभाव नहीं पड़ेगा।<ref name="Akritidis1" /> | इस तकनीक की लोकप्रियता के कारण बहुत से घुसपैठियों द्वारा रोकथाम के लिए इस पद्धति में से कई विक्रेता काम में इस्तेमाल होने वाले शेलकोड का पता लगाने के प्रयास में मशीन से नो-ऑप सिस्टम के निर्देशों की खोज करेंगे। यह ध्यान रखना महत्वपूर्ण है कि एनओपी-स्लेज में केवल पारंपरिक नो-ऑप मशीन निर्देश ही शामिल नहीं हैं; कोई भी निर्देश जो मशीन की स्थिति को उस बिंदु तक दूषित नहीं करता है जहां शेलकोड नहीं चलेगा, हार्डवेयर की सहायता से नो-ऑप के स्थान पर उपयोग किया जा सकता है। नतीजतन, शोषण करने वाले लेखकों के लिए बेतरतीब ढंग से चुने गए निर्देशों के साथ नो-ऑप स्लेज की रचना करना आम बात हो गई है, जिसका शेलकोड निष्पादन पर कोई वास्तविक प्रभाव नहीं पड़ेगा।<ref name="Akritidis1" /> | ||
इस विधि से दौरों के सफल होने की सम्भावना में बहुत सुधार आता है लेकिन यह बिना किसी समस्या के नहीं है। इस तकनीक का उपयोग करने वाले एक्सप्लॉइट्स को अभी भी भाग्य की कुछ मात्रा पर भरोसा करना चाहिए कि वे एनओपी-स्लेज क्षेत्र के भीतर ढेर पर ऑफ़सेट का अनुमान लगाएंगे।<ref name="klein1" /> सामान्यतया एक गलत अनुमान के परिणामस्वरूप लक्ष्य कार्यक्रम में हमलावर की गतिविधियों के प्रति सिस्टम प्रशासक को सचेत किया जा सकता है। एक और समस्या यह है कि एनओपी-स्लेज के लिए मेमोरी की एक बड़ी मात्रा की आवश्यकता होती है, जिसमें कि किसी भी उपयोग के लिए एक एनओपी-स्लेज पर्याप्त हो। यह एक समस्या हो सकती है जब प्रभावित बफर का आबंटित आकार बहुत छोटा हो और स्टैक की वर्तमान गहराई कम हो (अर्थात्, वर्तमान स्टैक फ्रेम के अंत से स्टैक की शुरुआत तक बहुत अधिक स्थान नहीं है)। अपनी समस्याओं के बावजूद, एनओपी-स्लेज ही एकमात्र तरीका है जो किसी दिए गए प्लेटफार्म, पर्यावरण, या परिस्थिति के लिए काम करता है,और इसलिए यह अभी भी एक महत्वपूर्ण तकनीक है। | |||
==== एक रजिस्टर तकनीक में संग्रहीत पते पर कूदें ==== | ==== एक रजिस्टर तकनीक में संग्रहीत पते पर कूदें ==== | ||
| Line 182: | Line 180: | ||
=== गहरा पैकेट निरीक्षण === | === गहरा पैकेट निरीक्षण === | ||
{{Main|Deep packet inspection}} | {{Main|Deep packet inspection}} | ||
पैकेट स्कैनिंग एक प्रभावी तरीका नहीं है क्योंकि यह केवल ज्ञात हमलों को रोक सकता है और ऐसे कई तरीके हैं जिनसे एनओपी-स्लेज को एन्कोड किया जा सकता है। हमलावरों द्वारा | |||
डीप पैकेट निरीक्षण (डीपीआई) के प्रयोग से नेटवर्क परिधि में, आक्रमण सिग्नेचर और अन्वेषण के प्रयोग द्वारा बफर ओवरफ्लो का पता लगाया जा सकता है। ये उन पैकेट्स को ब्लॉक करने में सक्षम हैं जिनमें ज्ञात हमले के हस्ताक्षर हैं, या यदि नो-ऑपरेशन निर्देशों की एक लंबी श्रृंखला है (एक नॉप-स्लेड के नाम से जाना जाता है), इन्हें एक बार तब इस्तेमाल किया जाता था जब शोषण के [[पेलोड]] की जगह थोड़ी सी चर होती थी। | |||
पैकेट स्कैनिंग एक प्रभावी तरीका नहीं है क्योंकि यह केवल ज्ञात हमलों को रोक सकता है और ऐसे कई तरीके हैं जिनसे एनओपी-स्लेज को एन्कोड किया जा सकता है। हमलावरों द्वारा इस्तेमाल किया जाने वाला शेलकोड अक्षरांकीय रूपान्तरण या स्वतः संशोधन ह्यूरिस्टिक पैकेट स्कैनर और घुसपैठ की जांच प्रणालियों द्वारा पहचान से बचने के लिए बनाया जा सकता है। | |||
=== परीक्षण === | === परीक्षण === | ||
बफर ओवरफ्लो को जाँचे और प्राकृतिक रूप से आने वाले बग्स पर पैचिंग करने से बफर ओवरफ्लो को रोका जा सकता है। उन्हें खोजने के लिए एक सामान्य स्वचालित तकनीक फ़ज़िंग है।<ref>{{cite web|url=http://raykoid666.wordpress.com|title=शोषक - सुरक्षा जानकारी और ट्यूटोरियल|access-date=2009-11-29}}</ref> कोर केस परीक्षण बफर अंतर्वाह को भी उजागर कर सकता है जैसा कि स्थैतिक विश्लेषण हो सकता है। <ref>{{Cite journal|last1=Larochelle|first1=David|last2=Evans|first2=David|date=13 August 2001|title=संभावित बफ़र ओवरफ़्लो भेद्यताओं का सांख्यिकीय रूप से पता लगाना|url=https://www.usenix.org/legacy/events/sec01/full_papers/larochelle/larochelle_html/|journal=USENIX Security Symposium|volume=32}}</ref> एक बार एक संभावित बफ़र अतिप्रवाह का पता चलने के बाद, इसे पैच किया जाना चाहिए; यह परीक्षण दृष्टिकोण को सॉफ्टवेयर के लिए उपयोगी बनाता है जो विकास में है, लेकिन लीगेसी सॉफ़्टवेयर के लिए कम उपयोगी है जो अब अनुरक्षित या समर्थित नहीं है। | |||
== इतिहास == | == इतिहास == | ||
Revision as of 21:34, 19 January 2023
सूचना सुरक्षा और प्रोग्रामिंग में, एक बफर अतिप्रवाह, या बफर ओवररन, एक विसंगति है जिसके द्वारा एक प्रोग्राम, बफर में डेटा लिखते समय बफर की सीमा को अतिक्रमित कर देते हैं और आसन्न स्मृति स्थानों पर उपरिलेखन करते हैं।
बफ़र्स, डेटा को धारण करने के लिए स्मृति के अलग-अलग क्षेत्र होते हैं, अक्सर इसे प्रोग्राम के एक भाग से दूसरे भाग में या प्रोग्रामों के बीच ले जाते समय। बफर ओवरफ्लो अक्सर खराब इनपुट द्वारा ट्रिगर किया जा सकता है;यदि कोई यह मानता है कि सभी इनपुट एक निश्चित आकार से छोटे होंगे और बफर उस आकार के लिए बनाया जाएगा तब एक असंगत लेनदेन, जो अधिक डेटा का उत्पादन करता है, बफर के अंत में इसे लिख सकता है। यदि यह संलग्न डेटा या निष्पादन योग्य कोड को अधिलेखित करता है, तो इसका परिणाम गलत परिणाम और क्रैश सहित अनिश्चित प्रोग्राम व्यवहार में हो सकता हैं।
बफर ओवरफ़्लो के व्यवहार का शोषण एक प्रसिद्ध सुरक्षा शोषण है। कई प्रणालियों पर, एक प्रोग्राम की स्मृति लेआउट, या पूरे सिस्टम को अच्छी तरह से परिभाषित किया गया है। बफर अधिप्रवाह उत्पन्न करने के लिए अभिकल्पित डेटा को भेज कर, निष्पादन योग्य कोड धारण करने के लिए ज्ञात क्षेत्रों में लिखना और दुर्भावनापूर्ण कोड के साथ इसे प्रतिस्थापित करना संभव है या प्रोग्राम की स्थिति से संबंधित डेटा को चुनकर अधिलेखित कर देता है, इसलिए ऐसा व्यवहार पैदा करता है जो मूल प्रोग्रामर द्वारा नहीं किया गया था। ऑपरेटिंग सिस्टम (ओएस) कोड में बफ़र्स व्यापक हैं, इसलिए ऐसे हमले करना संभव है जो विशेषाधिकार वृद्धि करते हैं और कंप्यूटर के संसाधनों की असीमित पहुंच बनाते हैं। 1988 में विख्यात मॉरिस वर्म ने इसे अपनी आक्रमण तकनीक में से एक बताया।
बफर ओवरफ्लो से जुड़ी प्रोग्रामिंग भाषाओं में सी और सी ++ शामिल हैं, जो मेमोरी के किसी भी हिस्से में डेटा के अभिगम या ओवरराइटिंग के विरुद्ध कोई अंतर्निहित सुरक्षा प्रदान नहीं करता है और सरणी पर लिखे गए डेटा को स्वतः जाँच नहीं करता है (अंतर्निहित बफर प्रकार) सरणी की सीमाओं के भीतर होता है। परिबद्ध जांच बफर बहिर्वाह को रोक सकती है परंतु अतिरिक्त कोड एवं संसाधन समय की आवश्यकता होती है। आधुनिक ऑपरेटिंग सिस्टम दुर्भावनापूर्ण बफर ओवरफ्लो का सामना करने के लिए, विशेष रूप से मेमोरी के लेआउट के यादृच्छिक रूप से, विभिन्न तकनीकों का उपयोग करता है, या जानबूझकर बफ़र्स के बीच में स्थान छोड़ कर उन क्षेत्रों ("कनारी") में लिखने वाली क्रियाओं की खोज करें।
तकनीकी विवरण
एक बफ़र अतिप्रवाह तब होता है जब एक बफ़र को लिखा गया डेटा भी अपर्याप्त सीमा जाँच के कारण गंतव्य बफ़र से सटे मेमोरी पतों में डेटा मान को दूषित कर जानकारी है।[1]: 41 यह तब हो सकता है जब डेटा को एक बफ़र से दूसरे बफ़र में पहले जाँचे बिना कॉपी किया जाता है कि डेटा डेस्टिनेशन बफ़र के भीतर फिट बैठता है।
उदाहरण
C (प्रोग्रामिंग लैंग्वेज) में व्यक्त किए गए निम्नलिखित उदाहरण में, एक प्रोग्राम में दो वेरिएबल्स होते हैं जो मेमोरी में आसन्न होते हैं: एक 8-बाइट-लंबा स्ट्रिंग बफर, A, और एक दो-बाइट endianness | बिग-एंडियन पूर्णांक, B।
<वाक्यविन्यास प्रकाश लैंग = सी> चार ए [8] =; अहस्ताक्षरित लघु बी = 1979; </वाक्यविन्यास हाइलाइट>
प्रारंभ में, A में शून्य बाइट्स के अलावा कुछ नहीं होता है, और B में 1979 की संख्या होती है।
| variable name | A | B | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| value | [null string] | 1979 | ||||||||
| hex value | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 07 | BB |
अब, कार्यक्रम अशक्त-समाप्त स्ट्रिंग को संग्रहीत करने का प्रयास करता है "excessive" ए बफर में एएससीआईआई एन्कोडिंग के साथ।
<वाक्यविन्यास प्रकाश लैंग = सी>
strcpy (ए, अत्यधिक);
</वाक्यविन्यास हाइलाइट>
"excessive" 9 अक्षर लंबा है और नल टर्मिनेटर सहित 10 बाइट्स को एन्कोड करता है, लेकिन A केवल 8 बाइट्स ले सकता है। स्ट्रिंग की लंबाई की जांच करने में विफल होने पर, यह B के मान को भी अधिलेखित कर देता है:
| variable name | A | B | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| value | 'e' | 'x' | 'c' | 'e' | 's' | 's' | 'i' | 'v' | 25856 | |
| hex | 65 | 78 | 63 | 65 | 73 | 73 | 69 | 76 | 65 | 00 |
B का मान अब अनजाने में वर्ण स्ट्रिंग के भाग से बनी संख्या से बदल दिया गया है। इस उदाहरण में e के बाद एक शून्य बाइट 25856 बन जाएगा।
आबंटित मेमोरी के अंत के बाद डेटा लिखना कभी-कभी ऑपरेटिंग सिस्टम द्वारा प्रक्रिया को समाप्त करने वाली विखंडन दोष त्रुटि उत्पन्न करने के लिए पता लगाया जा सकता है।
इस उदाहरण में बफ़र ओवरफ़्लो होने से रोकने के लिए, strcpy को कॉल को strlcpy से बदला जा सकता है, जो A की अधिकतम क्षमता लेता है (एक अशक्त-समाप्ति वर्ण सहित) एक अतिरिक्त पैरामीटर के रूप में और यह सुनिश्चित करता है कि डेटा की इस राशि से अधिक A को नहीं लिखा गया है:
<वाक्यविन्यास प्रकाश लैंग = सी> strlcpy (ए, अत्यधिक, आकार (ए)); </वाक्यविन्यास हाइलाइट>
उपलब्ध होने पर, strlcpy लाइब्रेरी फ़ंक्शन को strncpy से अधिक पसंद किया जाता है, जो स्रोत स्ट्रिंग की लंबाई बफ़र के आकार से अधिक या उसके बराबर होने पर गंतव्य बफ़र को शून्य-समाप्त नहीं करता है (तीसरा तर्क फ़ंक्शन को पास किया गया), इसलिए A को अशक्त-समाप्त नहीं किया जा सकता है और इसे मान्य C-शैली स्ट्रिंग के रूप में नहीं माना जा सकता है।
शोषण
बफर अधिप्रवाह भेद्यता का लाभ उठाने की तकनीक, ऑपरेटिंग सिस्टम और मेमोरी क्षेत्र द्वारा आर्किटेक्चर द्वारा बदलती रहती है। उदाहरण के लिए, ढेर पर शोषण (गतिशील आवंटित स्मृति के लिए उपयोग किया जाता है), कॉल स्टैक पर शोषण से स्पष्ट रूप से भिन्न है। सामान्य तौर पर, ढेर शोषण लक्ष्य प्रणाली पर उपयोग किए गए ढेर प्रबंधक पर निर्भर है, स्टैक शोषण वास्तुकला और कंपाइलर द्वारा उपयोग किए जाने वाले कॉलिंग सम्मेलन पर निर्भर है।
स्टैक-आधारित शोषण
एक तकनीकी रूप से इच्छुक उपयोगकर्ता कई तरीकों में से एक में अपने लाभ के लिए कार्यक्रम में हेरफेर करने के लिए स्टैक-आधारित बफर ओवरफ्लो का फायदा उठा सकता है: एक तकनीकी इच्छुक उपयोगकर्ता अनेक तरीकों से प्रोग्राम को अपने लाभ में बदलने के लिए ढेर आधारित बफर ओवरफ्लो का फायदा उठा सकता है:
- प्रोग्राम के बर्ताव को बदलने के लिए, एक लोकल चर पर लिख कर, जो स्टैक के कॉलोसिव बफर के निकट स्थित होता है।
- आमतौर पर हमलावर द्वारा चयनित कोड को इंगित करने के लिए एक स्टैक फ्रेम में रिटर्न पता को अधिलेखित करके शेलकोड कहा जाता है। फ़ंक्शन रिटर्न मिलने के बाद, निष्पादन हमलावर के शेलकोड पर फिर से शुरू होगा।
- शेलकोड को इंगित करने के लिए फंक्शन सूचक[2] या अपवाद हैंडलर को अधिलेखित करके, जो बाद में निष्पादित किया जाता है
- भिन्न स्टैक फ्रेम के स्थानीय चर (या सूचक) को अधिलेखित करके, जिसका प्रयोग बाद में उस फ्रेम के स्वामित्व वाले फंक्शन द्वारा किया जाएगा.
हमलावर इन कारनामों में से एक का उपयोग करने के लिए डेटा का डिजाइन करता है, फिर इस डेटा को सुभेद्य कोड द्वारा प्रयोक्ता को प्रदत्त बफर में रख देता है। यदि स्टैक बफर ओवरफ्लो को प्रभावित करने के लिए उपयोग किए जाने वाले उपयोगकर्ता द्वारा आपूर्ति किए गए डेटा का पता अप्रत्याशित है, तो रिमोट कोड निष्पादन के कारण स्टैक बफर ओवरफ़्लो का शोषण करना और अधिक कठिन हो जाता है। एक तकनीक जिसका प्रयोग बफर अधिप्रवाह के दोहन हेतु किया जा सकता है उसे" ट्रम्पोलिनिंग" कहा जाता है। उस तकनीक में, हमलावर कमज़ोर स्टैक बफर में सूचक खोज लेगा और उसके शेलकोड की उस संकेतक के सापेक्ष स्थिति की गणना करेगा। फिर, वे स्मृति में पहले से मौजूद निर्देश पर कूदने के लिए ओवरराइट का उपयोग करेंगे जो दूसरी छलांग लगाएगा, इस बार सूचक के सापेक्ष; वह दूसरी छलांग शेलकोड में शाखा निष्पादन करेगी। उपयुक्त निर्देश अक्सर बड़े कोड में मौजूद होते हैं। उदाहरण के लिए, मेटास्प्लोइट प्रोजेक्ट उपयुक्त ऑपकोड का एक डेटाबेस रखता है, हालांकि यह केवल विंडोज ऑपरेटिंग सिस्टम में पाए जाने वाले को सूचीबद्ध करता है।[3]
ढेर आधारित शोषण
पुंज डेटा क्षेत्र में घटित बफर अधिप्रवाह को पुंज अधिप्रवाह के रूप में निर्दिष्ट किया जाता है तथा यह स्टैक आधारित अंतर्वाह से भिन्न तरीके से समुपयोज्य होता है। पुंज पर मेमोरी, गतिशील रूप से अनुप्रयोग द्वारा रन-टाइम पर आवंटित की जाती है और सामान्यतया इसमें प्रोग्राम डेटा निहित रहता है। अनुप्रयोग को लिंक्ड सूची पॉइंटर्स जैसे आंतरिक संरचनाओं को अधिलेखित करने के लिए अधिलेखित करने के लिए विशिष्ट तरीके से इस डेटा को भ्रष्ट करने से शोषण किया जाता है। विहित हीप अधिप्रवाह तकनीक गतिशील स्मृति नियतन लिंकेज को अधिलेखित करती है। (जैसे कि malloc मेटा डेटा) और प्रोग्राम फंक्शन पॉइंटर को अधिलिखित करने के लिए परिणामी सूचक एक्सचेंज का उपयोग करता है।
जेपीईजी को संभालने में माइक्रोसॉफ्ट की जीडीआई + भेद्यता खतरे का एक उदाहरण है जो ढेर अतिप्रवाह पेश कर सकता है।[4]
शोषण में बाधाएँ
बफर में हेर-फेर, जो उसके पढ़ने या निष्पादित करने से पहले आता है, शोषण के प्रयास की विफलता का कारण बन सकता है। इन हस्तक्षेपों से शोषण के खतरे को कम किया जा सकता है लेकिन संभव है कि यह असंभव न हो। जोड़-तोड़ में ऊपर या निचले भाग में रूपांतरण, मेटचार्टर्स को हटाने और अल्फान्यूमेरिक तारों को फ़िल्टर करने का भी समावेश हो सकता है। हालाँकि, इन फ़िल्टर और जोड़-तोड़ को बायपास करने के लिए तकनीक मौजूद है; अल्फ़ान्यूमेरिक शेलकोड, बहुरूपी कोड, स्व-संशोधित कोड और रिटर्न-टू-लिबक हमले। अंतर्वेधन संसूचन पद्धति द्वारा संसूचन से बचने के लिए भी उसी विधि का प्रयोग किया जा सकता है। कुछ मामलों में, जहां कोड को यूनिकोड में परिवर्तित किया जाता है,[5] सहित, भेद्यता के खतरे को प्रकटीकरणकर्ताओं द्वारा केवल सेवा से इनकार के रूप में गलत तरीके से प्रस्तुत किया गया है जब वास्तव में स्वैच्छिक कोड का दूरस्थ निष्पादन संभव है।
शोषण की व्यावहारिकता
वास्तविक दुनिया में कारनामों में कई चुनौतियों का सामना करने के लिए मज़बूती से संचालित कारनामों पर काबू पाने की जरूरत है। इन कारकों में पतों में अशक्त बाइट्स, शेलकोड के स्थान में परिवर्तनशीलता, वातावरण के बीच अंतर और संचालन में विभिन्न प्रति-उपाय शामिल हैं।
एनओपी स्लेज तकनीक
एनओपी-स्लेज स्टैक बफर ओवरफ्लो के दोहन की सबसे पुरानी और सर्वाधिक प्रचलित तकनीक है।[6] यह लक्ष्य क्षेत्र के आकार को प्रभावी ढंग से बढ़ाकर बफर के सटीक पते को खोजने की समस्या का समाधान करता है। ऐसा करने के लिए, स्टैक के बहुत बड़े हिस्से नो-ऑप मशीन निर्देश के साथ दूषित हो गए हैं। हमलावर द्वारा प्रदान किए गए डेटा के अंत में, नो-ऑप निर्देशों के बाद, हमलावर बफर के शीर्ष पर एक सापेक्षिक छलांग लगाने के लिए एक निर्देश देता है जहां शेलकोड स्थित होता है। नो-ऑप्स के इस संग्रह को "एनओपी-स्लेज" के रूप में संदर्भित किया जाता है क्योंकि यदि रिटर्न एड्रेस को बफर के नो-ऑप क्षेत्र के भीतर किसी भी पते से ओवरराइट किया जाता है, निष्पादन नो-ऑप्स को "स्लाइड" करेगा जब तक कि यह अंत में कूद द्वारा वास्तविक दुर्भावनापूर्ण कोड पर पुनर्निर्देशित नहीं हो जाता। इस तकनीक के लिए हमलावर को अपेक्षाकृत छोटे शेलकोड के स्थान पर, एनओपी-स्लेज के स्टैक का अनुमान लगाने की आवश्यकता है।[7]
इस तकनीक की लोकप्रियता के कारण बहुत से घुसपैठियों द्वारा रोकथाम के लिए इस पद्धति में से कई विक्रेता काम में इस्तेमाल होने वाले शेलकोड का पता लगाने के प्रयास में मशीन से नो-ऑप सिस्टम के निर्देशों की खोज करेंगे। यह ध्यान रखना महत्वपूर्ण है कि एनओपी-स्लेज में केवल पारंपरिक नो-ऑप मशीन निर्देश ही शामिल नहीं हैं; कोई भी निर्देश जो मशीन की स्थिति को उस बिंदु तक दूषित नहीं करता है जहां शेलकोड नहीं चलेगा, हार्डवेयर की सहायता से नो-ऑप के स्थान पर उपयोग किया जा सकता है। नतीजतन, शोषण करने वाले लेखकों के लिए बेतरतीब ढंग से चुने गए निर्देशों के साथ नो-ऑप स्लेज की रचना करना आम बात हो गई है, जिसका शेलकोड निष्पादन पर कोई वास्तविक प्रभाव नहीं पड़ेगा।[8]
इस विधि से दौरों के सफल होने की सम्भावना में बहुत सुधार आता है लेकिन यह बिना किसी समस्या के नहीं है। इस तकनीक का उपयोग करने वाले एक्सप्लॉइट्स को अभी भी भाग्य की कुछ मात्रा पर भरोसा करना चाहिए कि वे एनओपी-स्लेज क्षेत्र के भीतर ढेर पर ऑफ़सेट का अनुमान लगाएंगे।[9] सामान्यतया एक गलत अनुमान के परिणामस्वरूप लक्ष्य कार्यक्रम में हमलावर की गतिविधियों के प्रति सिस्टम प्रशासक को सचेत किया जा सकता है। एक और समस्या यह है कि एनओपी-स्लेज के लिए मेमोरी की एक बड़ी मात्रा की आवश्यकता होती है, जिसमें कि किसी भी उपयोग के लिए एक एनओपी-स्लेज पर्याप्त हो। यह एक समस्या हो सकती है जब प्रभावित बफर का आबंटित आकार बहुत छोटा हो और स्टैक की वर्तमान गहराई कम हो (अर्थात्, वर्तमान स्टैक फ्रेम के अंत से स्टैक की शुरुआत तक बहुत अधिक स्थान नहीं है)। अपनी समस्याओं के बावजूद, एनओपी-स्लेज ही एकमात्र तरीका है जो किसी दिए गए प्लेटफार्म, पर्यावरण, या परिस्थिति के लिए काम करता है,और इसलिए यह अभी भी एक महत्वपूर्ण तकनीक है।
एक रजिस्टर तकनीक में संग्रहीत पते पर कूदें
रजिस्टर करने के लिए कूदने की तकनीक एनओपी-स्लेज के लिए अतिरिक्त कमरे की आवश्यकता के बिना और स्टैक ऑफसेट का अनुमान लगाए बिना स्टैक बफर ओवरफ्लो के विश्वसनीय शोषण की अनुमति देती है। रणनीति रिटर्न पॉइंटर को किसी ऐसी चीज़ से अधिलेखित करना है जो प्रोग्राम को एक रजिस्टर के भीतर संग्रहीत ज्ञात पॉइंटर पर कूदने का कारण बनेगी जो नियंत्रित बफर और इस प्रकार शेलकोड को इंगित करता है। उदाहरण के लिए, यदि रजिस्टर ए में बफर की शुरुआत के लिए एक सूचक होता है तो उस रजिस्टर को एक ऑपरेंड के रूप में लेने वाली किसी भी कूद या कॉल का उपयोग निष्पादन के प्रवाह को नियंत्रित करने के लिए किया जा सकता है।[10]
व्यावहारिक रूप से किसी प्रोग्राम में जानबूझकर किसी विशेष रजिस्टर में कूदने के निर्देश नहीं हो सकते हैं। पारंपरिक समाधान एक उपयुक्त ऑपकोड के अनजाने उदाहरण को खोजना है at a fixed location somewhere within the program memory. In figure [[:Image:JumpToEsp.png|बाईं ओर ई i386 के ऐसे अनजाने उदाहरण का एक उदाहरण है jmp esp निर्देश। इस निर्देश के लिए ओपकोड है FF E4.[11]यह दो-बाइट अनुक्रम निर्देश की शुरुआत से एक-बाइट ऑफ़सेट पर पाया जा सकता है call DbgPrint पते पर 0x7C941EED. यदि कोई हमलावर इस पते के साथ प्रोग्राम रिटर्न एड्रेस को ओवरराइट करता है, तो प्रोग्राम सबसे पहले जंप करेगा 0x7C941EED, ओपकोड की व्याख्या करें FF E4 के रूप में jmp esp निर्देश, और फिर स्टैक के शीर्ष पर कूद जाएगा और हमलावर के कोड को निष्पादित करेगा।[12]
जब यह तकनीक संभव हो जाती है तो भेद्यता की गंभीरता काफी बढ़ जाती है। ऐसा इसलिए है क्योंकि शोषण किसी हमले को चलाने के दौरान सफलता की आभासी गारंटी के साथ स्वचालित रूप से पर्याप्त रूप से काम करेगा। इस कारण से, यह इंटरनेट का कीड़ा में सबसे अधिक उपयोग की जाने वाली तकनीक है जो स्टैक बफर ओवरफ्लो कमजोरियों का फायदा उठाती है।[13]
यह विधि विंडोज प्लेटफॉर्म पर ओवरराइट किए गए रिटर्न एड्रेस के बाद शेलकोड को रखने की भी अनुमति देती है। चूंकि निष्पादन योग्य अधिकतर पते पर आधारित होते हैं 0x00400000 और x86 एक छोटा एंडियन आर्किटेक्चर है, रिटर्न एड्रेस का आखिरी बाइट एक शून्य होना चाहिए, जो बफर कॉपी को समाप्त करता है और उसके आगे कुछ भी नहीं लिखा जाता है। यह शेलकोड के आकार को बफ़र के आकार तक सीमित करता है, जो अत्यधिक प्रतिबंधात्मक हो सकता है। DLL उच्च मेमोरी में स्थित हैं (ऊपर 0x01000000) और ऐसे पते हैं जिनमें कोई शून्य बाइट नहीं है, इसलिए यह विधि अधिलेखित वापसी पते से नल बाइट्स (या अन्य अस्वीकृत वर्ण) को हटा सकती है। इस तरह से उपयोग की जाने वाली विधि को अक्सर डीएलएल ट्रैम्पोलिनिंग कहा जाता है।
सुरक्षात्मक प्रति उपाय
बफर ओवरफ्लो का पता लगाने या रोकने के लिए विभिन्न ट्रेडऑफ़ के साथ विभिन्न तकनीकों का उपयोग किया गया है। निम्नलिखित खंड उपलब्ध विकल्पों और कार्यान्वयनों का वर्णन करते हैं।
प्रोग्रामिंग भाषा का चुनाव
असेंबली और C/C++ लोकप्रिय प्रोग्रामिंग लैंग्वेज हैं जो बफर ओवरफ्लो के लिए कमजोर हैं, आंशिक रूप से क्योंकि वे मेमोरी तक सीधे पहुंच की अनुमति देते हैं और दृढ़ता से टाइप नहीं किए जाते हैं।[14] C स्मृति के किसी भी हिस्से में डेटा तक पहुँचने या अधिलेखित करने के विरुद्ध कोई अंतर्निहित सुरक्षा प्रदान नहीं करता है; अधिक विशेष रूप से, यह जाँच नहीं करता है कि बफ़र को लिखा गया डेटा उस बफ़र की सीमाओं के भीतर है। मानक C++ लाइब्रेरी डेटा को सुरक्षित रूप से बफ़र करने के कई तरीके प्रदान करती है, और C++ की मानक टेम्पलेट लाइब्रेरी (STL) ऐसे कंटेनर प्रदान करती है जो वैकल्पिक रूप से बाउंड चेक कर सकते हैं यदि प्रोग्रामर स्पष्ट रूप से डेटा एक्सेस करते समय चेक के लिए कॉल करता है। उदाहरण के लिए, ए vectorका सदस्य समारोह at() एक बाउंड चेक करता है और एक फेंकता है out_of_range सीमा जांच विफल होने पर अपवाद प्रबंधन।[15] हालाँकि, C ++ C की तरह ही व्यवहार करता है यदि सीमा जाँच को स्पष्ट रूप से नहीं कहा जाता है। सी के लिए बफर ओवरफ्लो से बचने की तकनीक भी मौजूद है।
भाषाएं जो दृढ़ता से टाइप की जाती हैं और सीधे मेमोरी एक्सेस की अनुमति नहीं देती हैं, जैसे कोबोल, जावा, पायथन, और अन्य, अधिकांश मामलों में बफर ओवरफ्लो होने से रोकती हैं।[14]C/C++ के अलावा कई प्रोग्रामिंग लैंग्वेज रनटाइम चेकिंग प्रदान करती हैं और कुछ मामलों में कंपाइल-टाइम चेकिंग भी करती हैं जो एक चेतावनी भेज सकती हैं या अपवाद बढ़ा सकती हैं जब C या C++ डेटा को ओवरराइट कर देगा और गलत परिणाम प्राप्त होने तक आगे के निर्देशों को निष्पादित करना जारी रखेगा जो हो सकता है या कार्यक्रम के क्रैश होने का कारण नहीं हो सकता है। ऐसी भाषाओं के उदाहरणों में एडा (प्रोग्रामिंग लैंग्वेज), एफिल (प्रोग्रामिंग लैंग्वेज), लिस्प (प्रोग्रामिंग भाषा), मॉड्यूल-2, स्मॉलटॉक, OCaml और ऐसे सी-डेरिवेटिव जैसे चक्रवात (प्रोग्रामिंग भाषा), जंग (प्रोग्रामिंग भाषा) और डी शामिल हैं। प्रोग्रामिंग भाषा)। जावा (सॉफ्टवेयर प्लेटफॉर्म) और .NET फ्रेमवर्क बायटेकोड वातावरण को भी सभी सरणियों पर सीमा जाँच की आवश्यकता होती है। लगभग हर व्याख्या की गई प्रोग्रामिंग भाषा बफर ओवरफ्लो से रक्षा करेगी, एक अच्छी तरह से परिभाषित त्रुटि स्थिति का संकेत देगी। अक्सर जहां एक भाषा सीमा जाँच करने के लिए पर्याप्त प्रकार की जानकारी प्रदान करती है, उसे सक्षम या अक्षम करने के लिए एक विकल्प प्रदान किया जाता है। स्टेटिक कोड विश्लेषण कई डायनेमिक बाउंड और टाइप चेक को हटा सकता है, लेकिन खराब कार्यान्वयन और अजीब मामले प्रदर्शन को काफी कम कर सकते हैं। सॉफ़्टवेयर इंजीनियरों को कौन सी भाषा और कंपाइलर सेटिंग का उपयोग करना है, यह तय करते समय सुरक्षा बनाम प्रदर्शन लागत के ट्रेडऑफ़ पर सावधानीपूर्वक विचार करना चाहिए।
सुरक्षित पुस्तकालयों का उपयोग
सी और सी ++ भाषाओं में बफर ओवरफ्लो की समस्या आम है क्योंकि वे डेटा प्रकारों के लिए कंटेनर के रूप में बफर के निम्न स्तर के प्रतिनिधित्व संबंधी विवरण का खुलासा करते हैं। बफर प्रबंधन करने वाले कोड में उच्च स्तर की शुद्धता बनाए रखने से बफर ओवरफ्लो से बचा जाना चाहिए। मानक पुस्तकालय कार्यों से बचने के लिए भी लंबे समय से सिफारिश की गई है, जो कि जांच की सीमा नहीं है, जैसे कि gets, scanf और strcpy. मोरिस वर्म ने शोषण किया a gets उंगली में कॉल करें।[16]
अच्छी तरह से लिखित और परीक्षण किए गए सार डेटा प्रकार पुस्तकालय जो केंद्रीकृत और स्वचालित रूप से बफर प्रबंधन करते हैं, जिसमें सीमा की जाँच भी शामिल है, बफर ओवरफ्लो की घटना और प्रभाव को कम कर सकते हैं। इन भाषाओं में दो मुख्य बिल्डिंग-ब्लॉक डेटा प्रकार जिनमें आमतौर पर बफर ओवरफ्लो होता है, स्ट्रिंग्स और एरेज़ हैं; इस प्रकार, इन डेटा प्रकारों में बफर ओवरफ़्लो को रोकने वाले पुस्तकालय आवश्यक कवरेज का विशाल बहुमत प्रदान कर सकते हैं। फिर भी, इन सुरक्षित पुस्तकालयों का सही ढंग से उपयोग करने में विफलता के परिणामस्वरूप बफर ओवरफ्लो और अन्य भेद्यताएं हो सकती हैं; और स्वाभाविक रूप से, पुस्तकालय में कोई भी सॉफ्टवेयर बग अपने आप में एक संभावित भेद्यता है। सुरक्षित लाइब्रेरी कार्यान्वयन में द बेटर स्ट्रिंग लाइब्रेरी शामिल है,[17] एम्बेड[18] और इरविन।[19] OpenBSD ऑपरेटिंग सिस्टम की सी पुस्तकालय strlcpy और strlcat फ़ंक्शंस प्रदान करती है, लेकिन ये पूर्ण सुरक्षित लाइब्रेरी कार्यान्वयनों की तुलना में अधिक सीमित हैं।
सितंबर 2007 में, सी मानक समिति द्वारा तैयार की गई तकनीकी रिपोर्ट 24731 प्रकाशित हुई थी;[20] यह उन कार्यों का एक सेट निर्दिष्ट करता है जो अतिरिक्त बफर-आकार पैरामीटर के साथ मानक सी लाइब्रेरी की स्ट्रिंग और I/O फ़ंक्शंस पर आधारित होते हैं। हालाँकि, बफर ओवरफ्लो को कम करने के उद्देश्य से इन कार्यों की प्रभावकारिता विवादित है; इसके लिए प्रति फ़ंक्शन कॉल के आधार पर प्रोग्रामर हस्तक्षेप की आवश्यकता होती है जो हस्तक्षेप के बराबर है जो समान पुराने मानक लाइब्रेरी फ़ंक्शंस बफर ओवरफ़्लो सुरक्षित बना सकता है।[21]
बफर अतिप्रवाह संरक्षण
बफर ओवरफ्लो सुरक्षा का उपयोग सबसे आम बफर ओवरफ्लो का पता लगाने के लिए किया जाता है, यह जाँच कर कि फ़ंक्शन के वापस आने पर कॉल स्टैक को बदला नहीं गया है। अगर इसे बदल दिया गया है, तो प्रोग्राम सेगमेंटेशन गलती से बाहर निकलता है। ऐसी तीन प्रणालियाँ हैं लिबसेफ,[22] और स्टैकगार्ड[23] और प्रोपुलिस[24] जीएनयू संकलक संग्रह पैच।
Microsoft का डेटा निष्पादन प्रतिबंध (DEP) मोड का कार्यान्वयन स्पष्ट रूप से संरचित अपवाद हैंडलर (SEH) के पॉइंटर को अधिलेखित होने से बचाता है।[25] स्टैक को दो में विभाजित करके मजबूत स्टैक सुरक्षा संभव है: डेटा के लिए एक और फ़ंक्शन रिटर्न के लिए एक। यह विभाजन फोर्थ (प्रोग्रामिंग भाषा) में मौजूद है, हालांकि यह सुरक्षा-आधारित डिज़ाइन निर्णय नहीं था। भले ही, यह बफर ओवरफ्लो का पूर्ण समाधान नहीं है, क्योंकि रिटर्न एड्रेस के अलावा संवेदनशील डेटा अभी भी अधिलेखित हो सकता है।
सूचक सुरक्षा
बफर ओवरफ्लो पॉइंटर (कंप्यूटर प्रोग्रामिंग) में हेरफेर करके काम करता है, जिसमें संग्रहीत पते शामिल हैं। प्वाइंटगार्ड को एक संकलक-विस्तार के रूप में प्रस्तावित किया गया था ताकि हमलावरों को पॉइंटर्स और पतों में मज़बूती से हेरफेर करने में सक्षम होने से रोका जा सके।[26] दृष्टिकोण उपयोग किए जाने से पहले और बाद में कंपाइलर को स्वचालित रूप से एक्सओआर-एन्कोड पॉइंटर्स में कोड जोड़कर काम करता है। सैद्धांतिक रूप से, क्योंकि हमलावर को यह नहीं पता होता है कि पॉइंटर को एनकोड/डीकोड करने के लिए किस मूल्य का उपयोग किया जाएगा, वह यह अनुमान नहीं लगा सकता है कि यदि वह इसे एक नए मूल्य के साथ अधिलेखित करता है तो यह क्या इंगित करेगा। प्वाइंटगार्ड कभी जारी नहीं किया गया था, लेकिन माइक्रोसॉफ्ट ने विंडोज एक्स पी एसपी2 और विंडोज सर्वर 2003 एसपी1 में एक समान दृष्टिकोण लागू किया।[27] सूचक सुरक्षा को स्वचालित सुविधा के रूप में लागू करने के बजाय, माइक्रोसॉफ्ट ने एक एपीआई रूटीन जोड़ा जिसे कॉल किया जा सकता है। यह बेहतर प्रदर्शन की अनुमति देता है (क्योंकि यह हर समय उपयोग नहीं किया जाता है), लेकिन यह जानने के लिए प्रोग्रामर पर बोझ डालता है कि यह कब आवश्यक है।
चूंकि एक्सओआर रैखिक है, एक हमलावर केवल एक पते के निचले बाइट्स को ओवरराइट करके एन्कोडेड पॉइंटर में हेरफेर करने में सक्षम हो सकता है। यह एक हमले को सफल होने की अनुमति दे सकता है यदि हमलावर कई बार शोषण का प्रयास करने में सक्षम है या एक सूचक को कई स्थानों में से एक को इंगित करने के लिए एक हमले को पूरा करने में सक्षम है (जैसे कि एनओपी स्लेज के भीतर कोई स्थान)।[28] Microsoft ने आंशिक अधिलेखन की इस कमजोरी को दूर करने के लिए अपनी एन्कोडिंग योजना में एक यादृच्छिक रोटेशन जोड़ा।[29]
निष्पादन योग्य स्थान सुरक्षा
निष्पादन योग्य स्थान सुरक्षा बफर ओवरफ्लो सुरक्षा के लिए एक दृष्टिकोण है जो ढेर या ढेर पर कोड के निष्पादन को रोकता है। एक हमलावर किसी प्रोग्राम की मेमोरी में मनमाना कोड डालने के लिए बफर ओवरफ्लो का उपयोग कर सकता है, लेकिन निष्पादन योग्य स्थान सुरक्षा के साथ, उस कोड को निष्पादित करने का कोई भी प्रयास एक अपवाद का कारण बनेगा।
कुछ CPU NX बिट (No eXecute) या XD बिट (eXecute Disabled) नामक सुविधा का समर्थन करते हैं, जो सॉफ्टवेयर के संयोजन के साथ पेजिंग (जैसे स्टैक और ढेर वाले) को पढ़ने योग्य और लिखने योग्य के रूप में चिह्नित करने के लिए उपयोग किया जा सकता है लेकिन नहीं निष्पादन योग्य।
कुछ यूनिक्स ऑपरेटिंग सिस्टम (जैसे OpenBSD, macOS) निष्पादन योग्य स्थान सुरक्षा (जैसे W^X) के साथ शिप होते हैं। कुछ वैकल्पिक पैकेजों में शामिल हैं:
Microsoft Windows के नए संस्करण भी निष्पादन योग्य स्थान सुरक्षा का समर्थन करते हैं, जिसे डेटा निष्पादन रोकथाम कहा जाता है।[33] मालिकाना सॉफ़्टवेयर ऐड-ऑन में शामिल हैं:
निष्पादन योग्य अंतरिक्ष सुरक्षा आम तौर पर रिटर्न-टू-लिबक हमलों, या किसी अन्य हमले के खिलाफ सुरक्षा नहीं करती है जो हमलावरों के कोड के निष्पादन पर भरोसा नहीं करती है। हालाँकि, ASLR का उपयोग करने वाले 64-बिट सिस्टम पर, जैसा कि नीचे वर्णित है, निष्पादन योग्य स्थान सुरक्षा ऐसे हमलों को निष्पादित करना कहीं अधिक कठिन बना देती है।
पता स्थान लेआउट यादृच्छिकीकरण
एड्रेस स्पेस लेआउट रेंडमाइजेशन (एएसएलआर) एक कंप्यूटर सुरक्षा सुविधा है जिसमें प्रमुख डेटा क्षेत्रों की स्थिति को व्यवस्थित करना शामिल है, जिसमें आमतौर पर निष्पादन योग्य आधार और लाइब्रेरी, हीप और स्टैक की स्थिति शामिल है, बेतरतीब ढंग से एक प्रक्रिया के पता स्थान में।
अप्रत्यक्ष स्मृति पतों का रैंडमाइजेशन जिस पर फ़ंक्शंस और चर पाए जा सकते हैं, बफर ओवरफ़्लो के शोषण को और अधिक कठिन बना सकते हैं, लेकिन असंभव नहीं। यह हमलावर को अलग-अलग सिस्टम के शोषण के प्रयास के लिए मजबूर करता है, जो इंटरनेट वर्म्स के प्रयासों को नाकाम कर देता है।[36] वर्चुअल एड्रेस स्पेस में प्रक्रियाओं और पुस्तकालयों को रिबेसिंग करने के लिए एक समान लेकिन कम प्रभावी तरीका है।
गहरा पैकेट निरीक्षण
डीप पैकेट निरीक्षण (डीपीआई) के प्रयोग से नेटवर्क परिधि में, आक्रमण सिग्नेचर और अन्वेषण के प्रयोग द्वारा बफर ओवरफ्लो का पता लगाया जा सकता है। ये उन पैकेट्स को ब्लॉक करने में सक्षम हैं जिनमें ज्ञात हमले के हस्ताक्षर हैं, या यदि नो-ऑपरेशन निर्देशों की एक लंबी श्रृंखला है (एक नॉप-स्लेड के नाम से जाना जाता है), इन्हें एक बार तब इस्तेमाल किया जाता था जब शोषण के पेलोड की जगह थोड़ी सी चर होती थी।
पैकेट स्कैनिंग एक प्रभावी तरीका नहीं है क्योंकि यह केवल ज्ञात हमलों को रोक सकता है और ऐसे कई तरीके हैं जिनसे एनओपी-स्लेज को एन्कोड किया जा सकता है। हमलावरों द्वारा इस्तेमाल किया जाने वाला शेलकोड अक्षरांकीय रूपान्तरण या स्वतः संशोधन ह्यूरिस्टिक पैकेट स्कैनर और घुसपैठ की जांच प्रणालियों द्वारा पहचान से बचने के लिए बनाया जा सकता है।
परीक्षण
बफर ओवरफ्लो को जाँचे और प्राकृतिक रूप से आने वाले बग्स पर पैचिंग करने से बफर ओवरफ्लो को रोका जा सकता है। उन्हें खोजने के लिए एक सामान्य स्वचालित तकनीक फ़ज़िंग है।[37] कोर केस परीक्षण बफर अंतर्वाह को भी उजागर कर सकता है जैसा कि स्थैतिक विश्लेषण हो सकता है। [38] एक बार एक संभावित बफ़र अतिप्रवाह का पता चलने के बाद, इसे पैच किया जाना चाहिए; यह परीक्षण दृष्टिकोण को सॉफ्टवेयर के लिए उपयोगी बनाता है जो विकास में है, लेकिन लीगेसी सॉफ़्टवेयर के लिए कम उपयोगी है जो अब अनुरक्षित या समर्थित नहीं है।
इतिहास
बफर ओवरफ्लो को 1972 के प्रारंभ में समझा गया तथा आंशिक रूप से सार्वजनिक रूप से अभिलेखित किया गया, जब कम्प्यूटर सुरक्षा प्रौद्योगिकी नियोजन अध्ययन ने इस तकनीक को प्रस्तुत किया: "इस फंक्शन को निष्पादित करने वाला कोड स्रोत और गंतव्य पता को ठीक से जाँच नहीं करता है, मॉनिटर के हिस्से को उपयोगकर्ता द्वारा मड़ने की अनुमति देता है। इसका उपयोग मॉनिटर में कोड इंजेक्ट करने के लिए किया जा सकता है जो उपयोगकर्ता को मशीन के नियंत्रण को जब्त करने की अनुमति देगा।[39] " आज, मॉनिटर को कर्नेल के रूप में संदर्भित किया जाएगा।
भारत में सबसे पहले से प्रलेखित बफर अधिप्रवाह का शत्रुतापूर्ण शोषण 1988 में हुआ था। यह मॉरिस वर्म द्वारा इंटरनेट पर खुद को प्रचारित करने के लिए उपयोग किए जाने वाले कई कारनामों में से एक था। शोषण किया गया कार्यक्रम यूनिक्स पर फिंगर नामक एक सेवा थी।[40] बाद में, 1995 में, थॉमस लोपेटिक ने बफर अधिप्रवाह को स्वतंत्र रूप से पुनः खोज लिया और बगट्रेक सुरक्षा मेलिंग सूची में अपने निष्कर्ष प्रकाशित किए।[41] एक साल बाद, 1996 में, एलियास लेवी (जिसे एलेफ वन के नाम से भी जाना जाता है) ने फ्रैक पत्रिका में "स्मैशिंग द स्टैक फॉर फन एंड प्रॉफिट" पेपर प्रकाशित किया,[42] स्टैक-आधारित बफर ओवरफ़्लो भेद्यताओं का शोषण करने के लिए चरण-दर-चरण परिचय।
तब से कम-से-कम दो प्रमुख इंटरनेट वर्म्स बफर ओवरफ्लो का फायदा उठा चुके हैं ताकि बड़ी संख्या में प्रणालियों के साथ समझौता हो सके। वर्ष 2001 में, कोड रेड वर्म ने माइक्रोसॉफ्ट की इंटरनेट सूचना सेवाओं (आईआईएस) 5.0 में बफर ओवरफ़्लो का उपयोग किया था।[43] और 2003 में एसक्यूएल स्लैमर वर्म ने माइक्रोसॉफ्ट एसक्यूएल सर्वर 2000 चलाने वाली मशीनों के साथ समझौता किया।[44]
वर्ष 2003 में लाइसेंस प्राप्त एक्सबॉक्स गेम्स में मौजूद बफर ओवरफ्लो का उपयोग लाइसेंस रहित सॉफ्टवेयर को अनुमति देने के लिए किया गया है, होमब्रू खेलों सहित, कंसोल पर हार्डवेयर संशोधनों की आवश्यकता के बिना, मोडचिप्स के रूप में जाना जाता है।[45] पीएस2 स्वतंत्रता का लाभ उठाने से प्लेस्टेशन 2 के लिए इसे प्राप्त करने के लिए बफर ओवरफ़्लो का भी प्रयोग किया गया। द लीजेंड ऑफ ज़ेल्डा: ट्वाइलाइट प्रिंसेस में बफर ओवरफ्लो का उपयोग करते हुए ट्वाइलाइट हैक ने डब्ल्यूआईआई के साथ भी ऐसा ही किया।
यह भी देखें
- अरब हँसे
- बफर ओवर-रीड
- कोडिंग सम्मेलन
- कंप्यूटर सुरक्षा
- फाइल समाप्त
- ढेर अतिप्रवाह
- मौत का पिंग
- पोर्ट स्कैनर
- रिटर्न-टू-लिबक अटैक
- सुरक्षा-महत्वपूर्ण प्रणाली
- सुरक्षा-केंद्रित ऑपरेटिंग सिस्टम
- स्व-संशोधित कोड
- सॉफ्टवेयर की गुणवत्ता
- शेलकोड
- ढेर बफर अतिप्रवाह
- अनियंत्रित प्रारूप स्ट्रिंग
संदर्भ
- ↑ {{#section:Template:Ref RFC/db/49|rfc4949ref}} {{#section:Template:Ref RFC/db/49|rfc4949status}}.
- ↑ "CORE-2007-0219: OpenBSD का IPv6 mbufs रिमोट कर्नेल बफर ओवरफ्लो". Retrieved 2007-05-15.
- ↑ "मेटास्प्लोइट ओपकोड डेटाबेस". Archived from the original on 12 May 2007. Retrieved 2007-05-15.
- ↑ "Microsoft तकनीक सुरक्षा बुलेटिन MS04-028". Microsoft. Archived from the original on 2011-08-04. Retrieved 2007-05-15.
- ↑ "यूनिकोड विस्तारित स्ट्रिंग्स में मनमाना शेलकोड बनाना" (PDF). Archived from the original (PDF) on 2006-01-05. Retrieved 2007-05-15.
- ↑ Vangelis (2004-12-08). "Stack-based Overflow Exploit: Introduction to Classical and Advanced Overflow Technique". Wowhacker via Neworder. Archived from the original (text) on August 18, 2007.
{{cite journal}}: Cite journal requires|journal=(help) - ↑ Balaban, Murat. "Buffer Overflows Demystified" (text). Enderunix.org.
{{cite journal}}: Cite journal requires|journal=(help) - ↑ Akritidis, P.; Evangelos P. Markatos; M. Polychronakis; Kostas D. Anagnostakis (2005). "STRIDE: Polymorphic Sled Detection through Instruction Sequence Analysis." (PDF). Proceedings of the 20th IFIP International Information Security Conference (IFIP/SEC 2005). IFIP International Information Security Conference. Archived from the original (PDF) on 2012-09-01. Retrieved 2012-03-04.
- ↑ Klein, Christian (September 2004). "Buffer Overflow" (PDF). Archived from the original (PDF) on 2007-09-28.
{{cite journal}}: Cite journal requires|journal=(help) - ↑ Shah, Saumil (2006). "Writing Metasploit Plugins: from vulnerability to exploit" (PDF). Hack In The Box. Kuala Lumpur. Retrieved 2012-03-04.
- ↑ Intel 64 and IA-32 Architectures Software Developer's Manual Volume 2A: Instruction Set Reference, A-M (PDF). Intel Corporation. May 2007. pp. 3–508. Archived from the original (PDF) on 2007-11-29.
- ↑ Alvarez, Sergio (2004-09-05). "Win32 Stack BufferOverFlow Real Life Vuln-Dev Process" (PDF). IT Security Consulting. Retrieved 2012-03-04.
{{cite journal}}: Cite journal requires|journal=(help) - ↑ Ukai, Yuji; Soeder, Derek; Permeh, Ryan (2004). "Environment Dependencies in Windows Exploitation". BlackHat Japan. Japan: eEye Digital Security. Retrieved 2012-03-04.
- ↑ 14.0 14.1 https://www.owasp.org/index.php/Buffer_OverflowsBuffer Overflows article on OWASP Archived 2016-08-29 at the Wayback Machine
- ↑ "वेक्टर :: पर - सी ++ संदर्भ". Cplusplus.com. Retrieved 2014-03-27.
- ↑ "संग्रहीत प्रति". wiretap.area.com. Archived from the original on 5 May 2001. Retrieved 6 June 2022.
- ↑ "द बेटर स्ट्रिंग लाइब्रेरी".
- ↑ "वीएसटीआर होमपेज". Archived from the original on 2017-03-05. Retrieved 2007-05-15.
- ↑ "इरविन होमपेज". Retrieved 2007-05-15.
- ↑ International Organization for Standardization (2007). "सूचना प्रौद्योगिकी - प्रोग्रामिंग भाषाएं, उनके वातावरण और सिस्टम सॉफ्टवेयर इंटरफेस - सी लाइब्रेरी के विस्तार - भाग 1: बाउंड-चेकिंग इंटरफेस". ISO Online Browsing Platform.
- ↑ "सीईआरटी सुरक्षित कोडिंग पहल". Archived from the original on December 28, 2012. Retrieved 2007-07-30.
- ↑ "FSF.org पर लिबसेफ". Retrieved 2007-05-20.
- ↑ "स्टैकगार्ड: कोवान एट अल द्वारा स्वचालित अनुकूली जांच और बफर-ओवरफ्लो हमलों की रोकथाम।" (PDF). Archived (PDF) from the original on 2022-10-09. Retrieved 2007-05-20.
- ↑ "X.ORG पर प्रोपुलिस". Archived from the original on 12 February 2007. Retrieved 2007-05-20.
- ↑ "Windows हार्डवेयर-प्रबलित डेटा निष्पादन रोकथाम को दरकिनार करना". Archived from the original on 2007-04-30. Retrieved 2007-05-20.
- ↑ "12वीं USENIX सुरक्षा संगोष्ठी - तकनीकी पेपर". www.usenix.org. Retrieved 3 April 2018.
- ↑ "पॉइंटर सबटरफ्यूज से बचाव (किंडा!)". msdn.com. Archived from the original on 2010-05-02. Retrieved 3 April 2018.
- ↑ "USENIX - द एडवांस्ड कंप्यूटिंग सिस्टम्स एसोसिएशन" (PDF). www.usenix.org. Archived (PDF) from the original on 2022-10-09. Retrieved 3 April 2018.
- ↑ "पॉइंटर सबटरफ्यूज (Redux) से बचाव". msdn.com. Archived from the original on 2009-12-19. Retrieved 3 April 2018.
- ↑ "पैक्स: पैक्स टीम का होमपेज". Retrieved 2007-06-03.
- ↑ "करनेलट्रॉप.ऑर्ग". Archived from the original on 2012-05-29. Retrieved 2007-06-03.
- ↑ "ओपनवॉल लिनक्स कर्नेल पैच 2.4.34-ओउ1". Archived from the original on 2012-02-19. Retrieved 2007-06-03.
- ↑ "Microsoft तकनीक: डेटा निष्पादन रोकथाम". Archived from the original on 2006-06-22. Retrieved 2006-06-30.
- ↑ "बफरशील्ड: विंडोज के लिए बफर ओवरफ्लो शोषण की रोकथाम". Retrieved 2007-06-03.
- ↑ "एनजीएसईसी स्टैक डिफेंडर". Archived from the original on 2007-05-13. Retrieved 2007-06-03.
- ↑ "PaX GRSecurity.net पर". Retrieved 2007-06-03.
- ↑ "शोषक - सुरक्षा जानकारी और ट्यूटोरियल". Retrieved 2009-11-29.
- ↑ Larochelle, David; Evans, David (13 August 2001). "संभावित बफ़र ओवरफ़्लो भेद्यताओं का सांख्यिकीय रूप से पता लगाना". USENIX Security Symposium. 32.
- ↑ "कंप्यूटर सुरक्षा प्रौद्योगिकी योजना अध्ययन" (PDF). p. 61. Archived from the original (PDF) on 2011-07-21. Retrieved 2007-11-02.
- ↑ "डोन सीले, यूटा विश्वविद्यालय द्वारा "ए टूर ऑफ़ द वर्म"". Archived from the original on 2007-05-20. Retrieved 2007-06-03.
- ↑ "Bugtraq सुरक्षा मेलिंग सूची संग्रह". Archived from the original on 2007-09-01. Retrieved 2007-06-03.
- ↑ "एलेफ वन द्वारा "स्मैशिंग द स्टैक फॉर फन एंड प्रॉफिट"". Retrieved 2012-09-05.
- ↑ "ईआई डिजिटल सुरक्षा". Retrieved 2007-06-03.
- ↑ "Microsoft तकनीक सुरक्षा बुलेटिन MS02-039". Microsoft. Archived from the original on 2008-03-07. Retrieved 2007-06-03.
- ↑ "हैकर बिना मॉड-चिप के Xbox सुरक्षा को तोड़ देता है". Archived from the original on 2007-09-27. Retrieved 2007-06-03.
बाहरी कड़ियाँ
- "Discovering and exploiting a remote buffer overflow vulnerability in an FTP server" by Raykoid666
- "Smashing the Stack for Fun and Profit" by Aleph One
- Gerg, Isaac (2005-05-02). "An Overview and Example of the Buffer-Overflow Exploit" (PDF). IAnewsletter. Information Assurance Technology Analysis Center. 7 (4): 16–21. Archived from the original (PDF) on 2006-09-27. Retrieved 2019-03-17.
- CERT Secure Coding Standards
- CERT Secure Coding Initiative
- Secure Coding in C and C++
- SANS: inside the buffer overflow attack
- "Advances in adjacent memory overflows" by Nomenumbra
- A Comparison of Buffer Overflow Prevention Implementations and Weaknesses
- More Security Whitepapers about Buffer Overflows
- Chapter 12: Writing Exploits III from Sockets, Shellcode, Porting & Coding: Reverse Engineering Exploits and Tool Coding for Security Professionals by James C. Foster (ISBN 1-59749-005-9). Detailed explanation of how to use Metasploit to develop a buffer overflow exploit from scratch.
- Computer Security Technology Planning Study, James P. Anderson, ESD-TR-73-51, ESD/AFSC, Hanscom AFB, Bedford, MA 01731 (October 1972) [NTIS AD-758 206]
- "Buffer Overflows: Anatomy of an Exploit" by Nevermore
- Secure Programming with GCC and GLibc Archived 2008-11-21 at the Wayback Machine (2008), by Marcel Holtmann
- "Criação de Exploits com Buffer Overflor – Parte 0 – Um pouco de teoria " (2018), by Helvio Junior (M4v3r1ck)
श्रेणी: सॉफ़्टवेयर बग श्रेणी:कंप्यूटर मेमोरी श्रेणी: कंप्यूटर सुरक्षा शोषण श्रेणी: उदाहरण सी कोड वाले लेख
