बफर ओवरफ्लो



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

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

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

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

तकनीकी विवरण
एक बफ़र अतिप्रवाह तब होता है जब एक बफ़र को लिखा गया डेटा भी अपर्याप्त सीमा जाँच के कारण गंतव्य बफ़र से सटे मेमोरी पतों में डेटा मान को दूषित कर जानकारी है। यह तब हो सकता है जब डेटा को एक बफ़र से दूसरे बफ़र में पहले जाँचे बिना कॉपी किया जाता है कि डेटा डेस्टिनेशन बफ़र के भीतर फिट बैठता है।

उदाहरण
C (प्रोग्रामिंग लैंग्वेज) में व्यक्त किए गए निम्नलिखित उदाहरण में, एक प्रोग्राम में दो वेरिएबल्स होते हैं जो मेमोरी में आसन्न होते हैं: एक 8-बाइट-लंबा स्ट्रिंग बफर, A, और एक दो-बाइट endianness | बिग-एंडियन पूर्णांक, B।

<वाक्यविन्यास प्रकाश लैंग = सी> चार ए [8] =; अहस्ताक्षरित लघु बी = 1979; 

प्रारंभ में, A में शून्य बाइट्स के अलावा कुछ नहीं होता है, और B में 1979 की संख्या होती है।

अब, कार्यक्रम अशक्त-समाप्त स्ट्रिंग को संग्रहीत करने का प्रयास करता है "excessive" ए बफर में एएससीआईआई एन्कोडिंग के साथ। <वाक्यविन्यास प्रकाश लैंग = सी> strcpy (ए, अत्यधिक);  "excessive" 9 अक्षर लंबा है और नल टर्मिनेटर सहित 10 बाइट्स को एन्कोड करता है, लेकिन A केवल 8 बाइट्स ले सकता है। स्ट्रिंग की लंबाई की जांच करने में विफल होने पर, यह B के मान को भी अधिलेखित कर देता है:

B का मान अब अनजाने में वर्ण स्ट्रिंग के भाग से बनी संख्या से बदल दिया गया है। इस उदाहरण में e के बाद एक शून्य बाइट 25856 बन जाएगा।

आबंटित मेमोरी के अंत के बाद डेटा लिखना कभी-कभी ऑपरेटिंग सिस्टम द्वारा प्रक्रिया को समाप्त करने वाली विखंडन दोष त्रुटि उत्पन्न करने के लिए पता लगाया जा सकता है।

इस उदाहरण में बफ़र ओवरफ़्लो होने से रोकने के लिए, strcpy को कॉल को strlcpy से बदला जा सकता है, जो A की अधिकतम क्षमता लेता है (एक अशक्त-समाप्ति वर्ण सहित) एक अतिरिक्त पैरामीटर के रूप में और यह सुनिश्चित करता है कि डेटा की इस राशि से अधिक A को नहीं लिखा गया है:

<वाक्यविन्यास प्रकाश लैंग = सी> strlcpy (ए, अत्यधिक, आकार (ए)); 

उपलब्ध होने पर, strlcpy लाइब्रेरी फ़ंक्शन को strncpy से अधिक पसंद किया जाता है, जो स्रोत स्ट्रिंग की लंबाई बफ़र के आकार से अधिक या उसके बराबर होने पर गंतव्य बफ़र को शून्य-समाप्त नहीं करता है (तीसरा तर्क फ़ंक्शन को पास किया गया), इसलिए A को अशक्त-समाप्त नहीं किया जा सकता है और इसे मान्य C-शैली स्ट्रिंग के रूप में नहीं माना जा सकता है।

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

स्टैक-आधारित शोषण
एक तकनीकी रूप से इच्छुक उपयोगकर्ता कई तरीकों में से एक में अपने लाभ के लिए कार्यक्रम में हेरफेर करने के लिए स्टैक-आधारित बफर ओवरफ्लो का फायदा उठा सकता है: एक तकनीकी इच्छुक उपयोगकर्ता अनेक तरीकों से प्रोग्राम को अपने लाभ में बदलने के लिए ढेर आधारित बफर ओवरफ्लो का फायदा उठा सकता है:

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

ढेर आधारित शोषण
हीप डेटा क्षेत्र में होने वाले बफर ओवरफ्लो को हीप ओवरफ्लो कहा जाता है और स्टैक-आधारित ओवरफ्लो से अलग तरीके से इसका शोषण किया जा सकता है। हीप पर मेमोरी गतिशील रूप से रन-टाइम पर एप्लिकेशन द्वारा आवंटित की जाती है और इसमें आमतौर पर प्रोग्राम डेटा होता है। इस डेटा को विशिष्ट तरीकों से दूषित करके शोषण किया जाता है जिससे एप्लिकेशन आंतरिक संरचनाओं जैसे कि लिंक्ड लिस्ट पॉइंटर्स को अधिलेखित कर देता है। कैनोनिकल हीप ओवरफ्लो तकनीक डायनेमिक मेमोरी एलोकेशन लिंकेज (जैसे malloc मेटा डेटा) को ओवरराइट करती है और प्रोग्राम फंक्शन पॉइंटर को ओवरराइट करने के लिए परिणामी पॉइंटर एक्सचेंज का उपयोग करती है।

माइक्रोसॉफ्ट के ग्राफिक्स डिवाइस इंटरफ़ेस | जेपीईजी को संभालने में जीडीआई + भेद्यता खतरे का एक उदाहरण है जो ढेर अतिप्रवाह पेश कर सकता है।

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

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

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

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

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

एक रजिस्टर तकनीक में संग्रहीत पते पर कूदें
रजिस्टर करने के लिए कूदने की तकनीक एनओपी-स्लेज के लिए अतिरिक्त कमरे की आवश्यकता के बिना और स्टैक ऑफसेट का अनुमान लगाए बिना स्टैक बफर ओवरफ्लो के विश्वसनीय शोषण की अनुमति देती है। रणनीति रिटर्न पॉइंटर को किसी ऐसी चीज़ से अधिलेखित करना है जो प्रोग्राम को एक रजिस्टर के भीतर संग्रहीत ज्ञात पॉइंटर पर कूदने का कारण बनेगी जो नियंत्रित बफर और इस प्रकार शेलकोड को इंगित करता है। उदाहरण के लिए, यदि रजिस्टर ए में बफर की शुरुआत के लिए एक सूचक होता है तो उस रजिस्टर को एक ऑपरेंड के रूप में लेने वाली किसी भी कूद या कॉल का उपयोग निष्पादन के प्रवाह को नियंत्रित करने के लिए किया जा सकता है। व्यावहारिक रूप से किसी प्रोग्राम में जानबूझकर किसी विशेष रजिस्टर में कूदने के निर्देश नहीं हो सकते हैं। पारंपरिक समाधान एक उपयुक्त ऑपकोड के अनजाने उदाहरण को खोजना है at a fixed location somewhere within the program memory. In figure [[:Image:JumpToEsp.png|बाईं ओर ई i386 के ऐसे अनजाने उदाहरण का एक उदाहरण है  निर्देश। इस निर्देश के लिए ओपकोड है  . यह दो-बाइट अनुक्रम निर्देश की शुरुआत से एक-बाइट ऑफ़सेट पर पाया जा सकता है   पते पर  . यदि कोई हमलावर इस पते के साथ प्रोग्राम रिटर्न एड्रेस को ओवरराइट करता है, तो प्रोग्राम सबसे पहले जंप करेगा , ओपकोड की व्याख्या करें   के रूप में   निर्देश, और फिर स्टैक के शीर्ष पर कूद जाएगा और हमलावर के कोड को निष्पादित करेगा।

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

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

सुरक्षात्मक प्रति उपाय
बफर ओवरफ्लो का पता लगाने या रोकने के लिए विभिन्न ट्रेडऑफ़ के साथ विभिन्न तकनीकों का उपयोग किया गया है। निम्नलिखित खंड उपलब्ध विकल्पों और कार्यान्वयनों का वर्णन करते हैं।

प्रोग्रामिंग भाषा का चुनाव
असेंबली और C/C++ लोकप्रिय प्रोग्रामिंग लैंग्वेज हैं जो बफर ओवरफ्लो के लिए कमजोर हैं, आंशिक रूप से क्योंकि वे मेमोरी तक सीधे पहुंच की अनुमति देते हैं और दृढ़ता से टाइप नहीं किए जाते हैं। C स्मृति के किसी भी हिस्से में डेटा तक पहुँचने या अधिलेखित करने के विरुद्ध कोई अंतर्निहित सुरक्षा प्रदान नहीं करता है; अधिक विशेष रूप से, यह जाँच नहीं करता है कि बफ़र को लिखा गया डेटा उस बफ़र की सीमाओं के भीतर है। मानक C++ लाइब्रेरी डेटा को सुरक्षित रूप से बफ़र करने के कई तरीके प्रदान करती है, और C++ की मानक टेम्पलेट लाइब्रेरी (STL) ऐसे कंटेनर प्रदान करती है जो वैकल्पिक रूप से बाउंड चेक कर सकते हैं यदि प्रोग्रामर स्पष्ट रूप से डेटा एक्सेस करते समय चेक के लिए कॉल करता है। उदाहरण के लिए, ए का सदस्य समारोह   एक बाउंड चेक करता है और एक फेंकता है   सीमा जांच विफल होने पर अपवाद प्रबंधन। हालाँकि, C ++ C की तरह ही व्यवहार करता है यदि सीमा जाँच को स्पष्ट रूप से नहीं कहा जाता है। सी के लिए बफर ओवरफ्लो से बचने की तकनीक भी मौजूद है।

भाषाएं जो दृढ़ता से टाइप की जाती हैं और सीधे मेमोरी एक्सेस की अनुमति नहीं देती हैं, जैसे कोबोल, जावा, पायथन, और अन्य, अधिकांश मामलों में बफर ओवरफ्लो होने से रोकती हैं। C/C++ के अलावा कई प्रोग्रामिंग लैंग्वेज रनटाइम चेकिंग प्रदान करती हैं और कुछ मामलों में कंपाइल-टाइम चेकिंग भी करती हैं जो एक चेतावनी भेज सकती हैं या अपवाद बढ़ा सकती हैं जब C या C++ डेटा को ओवरराइट कर देगा और गलत परिणाम प्राप्त होने तक आगे के निर्देशों को निष्पादित करना जारी रखेगा जो हो सकता है या कार्यक्रम के क्रैश होने का कारण नहीं हो सकता है। ऐसी भाषाओं के उदाहरणों में एडा (प्रोग्रामिंग लैंग्वेज), एफिल (प्रोग्रामिंग लैंग्वेज), लिस्प (प्रोग्रामिंग भाषा), मॉड्यूल-2, स्मॉलटॉक, OCaml और ऐसे सी-डेरिवेटिव जैसे चक्रवात (प्रोग्रामिंग भाषा), जंग (प्रोग्रामिंग भाषा) और डी शामिल हैं। प्रोग्रामिंग भाषा)। जावा (सॉफ्टवेयर प्लेटफॉर्म) और .NET फ्रेमवर्क बायटेकोड वातावरण को भी सभी सरणियों पर सीमा जाँच की आवश्यकता होती है। लगभग हर व्याख्या की गई प्रोग्रामिंग भाषा बफर ओवरफ्लो से रक्षा करेगी, एक अच्छी तरह से परिभाषित त्रुटि स्थिति का संकेत देगी। अक्सर जहां एक भाषा सीमा जाँच करने के लिए पर्याप्त प्रकार की जानकारी प्रदान करती है, उसे सक्षम या अक्षम करने के लिए एक विकल्प प्रदान किया जाता है। स्टेटिक कोड विश्लेषण कई डायनेमिक बाउंड और टाइप चेक को हटा सकता है, लेकिन खराब कार्यान्वयन और अजीब मामले प्रदर्शन को काफी कम कर सकते हैं। सॉफ़्टवेयर इंजीनियरों को कौन सी भाषा और कंपाइलर सेटिंग का उपयोग करना है, यह तय करते समय सुरक्षा बनाम प्रदर्शन लागत के ट्रेडऑफ़ पर सावधानीपूर्वक विचार करना चाहिए।

सुरक्षित पुस्तकालयों का उपयोग
सी और सी ++ भाषाओं में बफर ओवरफ्लो की समस्या आम है क्योंकि वे डेटा प्रकारों के लिए कंटेनर के रूप में बफर के निम्न स्तर के प्रतिनिधित्व संबंधी विवरण का खुलासा करते हैं। बफर प्रबंधन करने वाले कोड में उच्च स्तर की शुद्धता बनाए रखने से बफर ओवरफ्लो से बचा जाना चाहिए। मानक पुस्तकालय कार्यों से बचने के लिए भी लंबे समय से सिफारिश की गई है, जो कि जांच की सीमा नहीं है, जैसे कि,   और. मोरिस वर्म ने शोषण किया a  उंगली में कॉल करें। अच्छी तरह से लिखित और परीक्षण किए गए सार डेटा प्रकार पुस्तकालय जो केंद्रीकृत और स्वचालित रूप से बफर प्रबंधन करते हैं, जिसमें सीमा की जाँच भी शामिल है, बफर ओवरफ्लो की घटना और प्रभाव को कम कर सकते हैं। इन भाषाओं में दो मुख्य बिल्डिंग-ब्लॉक डेटा प्रकार जिनमें आमतौर पर बफर ओवरफ्लो होता है, स्ट्रिंग्स और एरेज़ हैं; इस प्रकार, इन डेटा प्रकारों में बफर ओवरफ़्लो को रोकने वाले पुस्तकालय आवश्यक कवरेज का विशाल बहुमत प्रदान कर सकते हैं। फिर भी, इन सुरक्षित पुस्तकालयों का सही ढंग से उपयोग करने में विफलता के परिणामस्वरूप बफर ओवरफ्लो और अन्य भेद्यताएं हो सकती हैं; और स्वाभाविक रूप से, पुस्तकालय में कोई भी सॉफ्टवेयर बग अपने आप में एक संभावित भेद्यता है। सुरक्षित लाइब्रेरी कार्यान्वयन में द बेटर स्ट्रिंग लाइब्रेरी शामिल है, एम्बेड और इरविन। OpenBSD ऑपरेटिंग सिस्टम की सी पुस्तकालय strlcpy और strlcat फ़ंक्शंस प्रदान करती है, लेकिन ये पूर्ण सुरक्षित लाइब्रेरी कार्यान्वयनों की तुलना में अधिक सीमित हैं।

सितंबर 2007 में, सी मानक समिति द्वारा तैयार की गई तकनीकी रिपोर्ट 24731 प्रकाशित हुई थी; यह उन कार्यों का एक सेट निर्दिष्ट करता है जो अतिरिक्त बफर-आकार पैरामीटर के साथ मानक सी लाइब्रेरी की स्ट्रिंग और I/O फ़ंक्शंस पर आधारित होते हैं। हालाँकि, बफर ओवरफ्लो को कम करने के उद्देश्य से इन कार्यों की प्रभावकारिता विवादित है; इसके लिए प्रति फ़ंक्शन कॉल के आधार पर प्रोग्रामर हस्तक्षेप की आवश्यकता होती है जो हस्तक्षेप के बराबर है जो समान पुराने मानक लाइब्रेरी फ़ंक्शंस बफर ओवरफ़्लो सुरक्षित बना सकता है।

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

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

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

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

निष्पादन योग्य स्थान सुरक्षा
निष्पादन योग्य स्थान सुरक्षा बफर ओवरफ्लो सुरक्षा के लिए एक दृष्टिकोण है जो ढेर या ढेर पर कोड के निष्पादन को रोकता है। एक हमलावर किसी प्रोग्राम की मेमोरी में मनमाना कोड डालने के लिए बफर ओवरफ्लो का उपयोग कर सकता है, लेकिन निष्पादन योग्य स्थान सुरक्षा के साथ, उस कोड को निष्पादित करने का कोई भी प्रयास एक अपवाद का कारण बनेगा।

कुछ CPU NX बिट (No eXecute) या XD बिट (eXecute Disabled) नामक सुविधा का समर्थन करते हैं, जो सॉफ्टवेयर के संयोजन के साथ पेजिंग (जैसे स्टैक और ढेर वाले) को पढ़ने योग्य और लिखने योग्य के रूप में चिह्नित करने के लिए उपयोग किया जा सकता है लेकिन नहीं निष्पादन योग्य।

कुछ यूनिक्स ऑपरेटिंग सिस्टम (जैसे OpenBSD, macOS) निष्पादन योग्य स्थान सुरक्षा (जैसे W^X) के साथ शिप होते हैं। कुछ वैकल्पिक पैकेजों में शामिल हैं:

Microsoft Windows के नए संस्करण भी निष्पादन योग्य स्थान सुरक्षा का समर्थन करते हैं, जिसे डेटा निष्पादन रोकथाम कहा जाता है। मालिकाना सॉफ़्टवेयर ऐड-ऑन में शामिल हैं:
 * शांति
 * एक्सेक शील्ड
 * ओपनवेल

निष्पादन योग्य अंतरिक्ष सुरक्षा आम तौर पर रिटर्न-टू-लिबक हमलों, या किसी अन्य हमले के खिलाफ सुरक्षा नहीं करती है जो हमलावरों के कोड के निष्पादन पर भरोसा नहीं करती है। हालाँकि, ASLR का उपयोग करने वाले 64-बिट सिस्टम पर, जैसा कि नीचे वर्णित है, निष्पादन योग्य स्थान सुरक्षा ऐसे हमलों को निष्पादित करना कहीं अधिक कठिन बना देती है।
 * बफरशील्ड
 * स्टैक डिफेंडर

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

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

गहरा पैकेट निरीक्षण
डीप पैकेट इंस्पेक्शन (DPI) का उपयोग, नेटवर्क परिधि पर, अटैक सिग्नेचर और ह्यूरिस्टिक (कंप्यूटर साइंस) के उपयोग द्वारा बफर ओवरफ्लो का फायदा उठाने के लिए बहुत ही बुनियादी दूरस्थ प्रयासों का पता लगा सकता है। ये उन पैकेटों को ब्लॉक करने में सक्षम हैं जिनमें एक ज्ञात हमले के हस्ताक्षर हैं, या यदि नो-ऑपरेशन निर्देशों (एनओपी-स्लेज के रूप में जाना जाता है) की एक लंबी श्रृंखला का पता चला है, तो इनका उपयोग एक बार शोषण के पेलोड (सॉफ्टवेयर) के स्थान पर किया गया था। थोड़ा परिवर्तनशील है।

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

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

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

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

तब से कम-से-कम दो प्रमुख इंटरनेट वर्म्स बफर ओवरफ्लो का फायदा उठा चुके हैं ताकि बड़ी संख्या में प्रणालियों के साथ समझौता हो सके। वर्ष 2001 में, कोड रेड वर्म ने माइक्रोसॉफ्ट की इंटरनेट सूचना सेवाओं (आईआईएस) 5.0 में बफर ओवरफ़्लो का उपयोग किया था। और 2003 में एसक्यूएल स्लैमर वर्म ने माइक्रोसॉफ्ट एसक्यूएल सर्वर 2000 चलाने वाली मशीनों के साथ समझौता किया।

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

यह भी देखें

 * अरब हँसे
 * बफर ओवर-रीड
 * कोडिंग सम्मेलन
 * कंप्यूटर सुरक्षा
 * फाइल समाप्त
 * ढेर अतिप्रवाह
 * मौत का पिंग
 * पोर्ट स्कैनर
 * रिटर्न-टू-लिबक अटैक
 * सुरक्षा-महत्वपूर्ण प्रणाली
 * सुरक्षा-केंद्रित ऑपरेटिंग सिस्टम
 * स्व-संशोधित कोड
 * सॉफ्टवेयर की गुणवत्ता
 * शेलकोड
 * ढेर बफर अतिप्रवाह
 * अनियंत्रित प्रारूप स्ट्रिंग

बाहरी कड़ियाँ

 * "Discovering and exploiting a remote buffer overflow vulnerability in an FTP server" by Raykoid666
 * "Smashing the Stack for Fun and Profit" by Aleph One
 * 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 (2008), by Marcel Holtmann
 * "Criação de Exploits com Buffer Overflor – Parte 0 – Um pouco de teoria " (2018), by Helvio Junior (M4v3r1ck)
 * "Criação de Exploits com Buffer Overflor – Parte 0 – Um pouco de teoria " (2018), by Helvio Junior (M4v3r1ck)