बफर ओवरफ्लो



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एनओपी स्लेज तकनीक


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

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

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

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

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

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

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

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

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

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

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

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

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

माइक्रोसॉफ्ट का डेटा निष्पादन प्रतिबंध (डीइपी) मोड का कार्यान्वयन स्पष्ट रूप से संरचित अपवाद हैंडलर (एसइएच) के पॉइंटर को अधिलेखित होने से बचाता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

इतिहास
बफ़र अधिकता को 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)