स्टैक बफर ओवरफ्लो: Difference between revisions
m (Deepak moved page ढेर बफर अतिप्रवाह to स्टैक बफर ओवरफ्लो without leaving a redirect) |
No edit summary |
||
Line 1: | Line 1: | ||
{{Short description|Software anomaly}} | {{Short description|Software anomaly}} | ||
{{other uses| | {{other uses|स्टैक ओवरफ्लो (बहुविकल्पी)}} | ||
सॉफ़्टवेयर में, स्टैक बफ़र ओवरफ़्लो या स्टैक बफ़र ओवररन तब होता है जब कोई प्रोग्राम इच्छित डेटा संरचना के बाहर प्रोग्राम के [[कॉल स्टैक]] पर [[ स्मृति ]] पते पर लिखता है, जो | सॉफ़्टवेयर में, स्टैक बफ़र ओवरफ़्लो या स्टैक बफ़र ओवररन तब होता है जब कोई प्रोग्राम इच्छित डेटा संरचना के बाहर प्रोग्राम के [[कॉल स्टैक]] पर [[ स्मृति ]] पते पर लिखता है, जो सामान्यतः एक निश्चित-लंबाई [[डेटा बफर]] होता है।<ref name="cert1">{{cite web |last1=Fithen |first1=William L. |last2=Seacord |first2=Robert |publisher=[[US CERT]] |title=वीटी-एमबी। स्मृति सीमा का उल्लंघन|url=https://www.securecoding.cert.org/confluence/display/sci/VT-MB.+Violation+of+Memory+Bounds |date=2007-03-27}}</ref><ref name="dowd">{{cite book |last1=Dowd |first1=Mark |last2=McDonald |first2=John |last3=Schuh |first3=Justin |title=सॉफ्टवेयर सुरक्षा आकलन की कला|publisher=[[Addison Wesley]] |date=November 2006 |pages=169–196 |isbn=0-321-44442-6}}</ref> | ||
स्टैक [[ बफ़र अधिकता ]] बग तब होते हैं जब कोई प्रोग्राम स्टैक पर स्थित बफर को वास्तव में उस बफर के लिए आवंटित डेटा से अधिक डेटा लिखता है। यह लगभग हमेशा स्टैक पर आसन्न डेटा के भ्रष्टाचार का परिणाम होता है, और ऐसे मामलों में जहां अतिप्रवाह गलती से | स्टैक [[ बफ़र अधिकता ]] बग तब होते हैं जब कोई प्रोग्राम स्टैक पर स्थित बफर को वास्तव में उस बफर के लिए आवंटित डेटा से अधिक डेटा लिखता है। यह लगभग हमेशा स्टैक पर आसन्न डेटा के भ्रष्टाचार का परिणाम होता है, और ऐसे मामलों में जहां अतिप्रवाह गलती से प्रारंभ हो गया था, अधिकांशतः प्रोग्राम को क्रैश या गलत विधि से संचालित करने का कारण बनता है। स्टैक बफर ओवरफ्लो एक प्रकार का अधिक सामान्य प्रोग्रामिंग खराबी है जिसे बफर ओवरफ्लो (या बफर ओवररन) के रूप में जाना जाता है।<ref name="cert1"/>स्टैक पर एक बफ़र को ओवरफ़िल करने से हीप पर एक बफ़र को ओवरफ़िल करने की समानता में प्रोग्राम के निष्पादन को पटरी से उतारने की संभावना अधिक होती है क्योंकि स्टैक में सभी सक्रिय फ़ंक्शन कॉल के लिए रिटर्न एड्रेस होते हैं। | ||
स्टैक स्मैशिंग के रूप में जाने जाने वाले हमले के हिस्से के रूप में एक स्टैक बफर ओवरफ़्लो जानबूझकर हो सकता है। यदि प्रभावित प्रोग्राम विशेष विशेषाधिकारों के साथ चल रहा है, या अविश्वसनीय नेटवर्क होस्ट (जैसे [[ वेब सर्वर ]]) से डेटा स्वीकार करता है तो बग एक संभावित [[सुरक्षा भेद्यता]] है। यदि स्टैक बफ़र एक अविश्वसनीय उपयोगकर्ता द्वारा प्रदान किए गए डेटा से भरा हुआ है, तो वह उपयोगकर्ता स्टैक को इस तरह से दूषित कर सकता है जैसे निष्पादन योग्य कोड को रनिंग प्रोग्राम में इंजेक्ट कर सकता है और प्रक्रिया को नियंत्रित कर सकता है। यह [[हैकर (कंप्यूटर सुरक्षा)]] के लिए कंप्यूटर पर अनधिकृत पहुंच प्राप्त करने के सबसे पुराने और अधिक विश्वसनीय तरीकों में से एक है।<ref name="aleph1">{{cite journal |last=Levy |first=Elias |author-link=Elias Levy |title=आनंद और लाभ के लिए ढेर को नष्ट करना|journal=[[Phrack]] |volume=7 |issue=49 |pages=14 |date=1996-11-08 |url=http://www.phrack.org/issues/49/14.html#article}}</ref><ref name="microsoft1">{{Cite journal | doi = 10.1109/MSP.2004.36| title = Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns| journal = IEEE Security and Privacy Magazine| volume = 2| issue = 4| pages = 20–27| date=July–August 2004 | last1 = Pincus | first1 = J.| last2 = Baker | first2 = B.| s2cid = 6647392| url = http://www.cs.berkeley.edu/~daw/teaching/cs261-f07/reading/beyondsmashing.pdf}}</ref><ref name="forest">{{cite web|author=Burebista<!-- aanton@reversedhell.net --> |title=स्टैक ओवरफ़्लो|url=http://www.securityforest.com/downloads/educationtree/stack_overflows.pdf |url-status=dead |archive-url=https://web.archive.org/web/20070928100343/http://www.securityforest.com/downloads/educationtree/stack_overflows.pdf |archive-date=September 28, 2007}} {{Dead link|date=July 2022}}</ref> | स्टैक स्मैशिंग के रूप में जाने जाने वाले हमले के हिस्से के रूप में एक स्टैक बफर ओवरफ़्लो जानबूझकर हो सकता है। यदि प्रभावित प्रोग्राम विशेष विशेषाधिकारों के साथ चल रहा है, या अविश्वसनीय नेटवर्क होस्ट (जैसे [[ वेब सर्वर ]]) से डेटा स्वीकार करता है तो बग एक संभावित [[सुरक्षा भेद्यता]] है। यदि स्टैक बफ़र एक अविश्वसनीय उपयोगकर्ता द्वारा प्रदान किए गए डेटा से भरा हुआ है, तो वह उपयोगकर्ता स्टैक को इस तरह से दूषित कर सकता है जैसे निष्पादन योग्य कोड को रनिंग प्रोग्राम में इंजेक्ट कर सकता है और प्रक्रिया को नियंत्रित कर सकता है। यह [[हैकर (कंप्यूटर सुरक्षा)]] के लिए कंप्यूटर पर अनधिकृत पहुंच प्राप्त करने के सबसे पुराने और अधिक विश्वसनीय तरीकों में से एक है।<ref name="aleph1">{{cite journal |last=Levy |first=Elias |author-link=Elias Levy |title=आनंद और लाभ के लिए ढेर को नष्ट करना|journal=[[Phrack]] |volume=7 |issue=49 |pages=14 |date=1996-11-08 |url=http://www.phrack.org/issues/49/14.html#article}}</ref><ref name="microsoft1">{{Cite journal | doi = 10.1109/MSP.2004.36| title = Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns| journal = IEEE Security and Privacy Magazine| volume = 2| issue = 4| pages = 20–27| date=July–August 2004 | last1 = Pincus | first1 = J.| last2 = Baker | first2 = B.| s2cid = 6647392| url = http://www.cs.berkeley.edu/~daw/teaching/cs261-f07/reading/beyondsmashing.pdf}}</ref><ref name="forest">{{cite web|author=Burebista<!-- aanton@reversedhell.net --> |title=स्टैक ओवरफ़्लो|url=http://www.securityforest.com/downloads/educationtree/stack_overflows.pdf |url-status=dead |archive-url=https://web.archive.org/web/20070928100343/http://www.securityforest.com/downloads/educationtree/stack_overflows.pdf |archive-date=September 28, 2007}} {{Dead link|date=July 2022}}</ref> | ||
Line 9: | Line 9: | ||
== स्टैक बफर ओवरफ्लो का शोषण == | == स्टैक बफर ओवरफ्लो का शोषण == | ||
एक्सप्लॉइट (कंप्यूटर सुरक्षा) के लिए एक स्टैक-आधारित बफर ओवरफ़्लो के लिए कैननिकल विधि हमलावर-नियंत्रित डेटा ( | एक्सप्लॉइट (कंप्यूटर सुरक्षा) के लिए एक स्टैक-आधारित बफर ओवरफ़्लो के लिए कैननिकल विधि हमलावर-नियंत्रित डेटा (सामान्यतः स्टैक पर ही) के सूचक के साथ फ़ंक्शन रिटर्न एड्रेस को ओवरराइट करना है।<ref name="aleph1"/><ref name="openbsd1">{{cite conference |first=Louis |last=Bertrand |url=http://www.openbsd.org/slides/musess_2002/img16.htm |title=OpenBSD: Fix the Bugs, Secure the System |book-title=MUSESS '02: McMaster University Software Engineering Symposium |year=2002 |url-status=dead |archive-url=https://web.archive.org/web/20070930023522/http://www.openbsd.org/slides/musess_2002/img16.htm |archive-date=2007-09-30 }}</ref> इसके द्वारा दर्शाया गया है <code>[[strcpy|strcpy()]]</code> निम्नलिखित उदाहरण में: | ||
<syntaxhighlight lang=c> | <syntaxhighlight lang=c> | ||
Line 36: | Line 36: | ||
|valign="top"| [[Image:Stack Overflow 4.png|none|thumb|207px|C. - "AAAAAAAAAAAAAAAAAAAA\x08\x35\xC0\x80" is the first command line argument.]] | |valign="top"| [[Image:Stack Overflow 4.png|none|thumb|207px|C. - "AAAAAAAAAAAAAAAAAAAA\x08\x35\xC0\x80" is the first command line argument.]] | ||
|} | |} | ||
उपरोक्त आकृति C में, जब कमांड लाइन पर 11 बाइट्स से बड़ा तर्क दिया जाता है <code>foo()</code> स्थानीय स्टैक डेटा, सहेजे गए फ़्रेम पॉइंटर और सबसे महत्वपूर्ण रूप से रिटर्न एड्रेस को ओवरराइट करता है। कब <code>foo()</code> रिटर्न यह स्टैक से वापसी पता पॉप करता है और उस पते पर कूदता है (यानी उस पते से निर्देश निष्पादित करना | उपरोक्त आकृति C में, जब कमांड लाइन पर 11 बाइट्स से बड़ा तर्क दिया जाता है <code>foo()</code> स्थानीय स्टैक डेटा, सहेजे गए फ़्रेम पॉइंटर और सबसे महत्वपूर्ण रूप से रिटर्न एड्रेस को ओवरराइट करता है। कब <code>foo()</code> रिटर्न यह स्टैक से वापसी पता पॉप करता है और उस पते पर कूदता है (यानी उस पते से निर्देश निष्पादित करना प्रारंभ करता है)। इस प्रकार, हमलावर ने स्टैक बफर के पॉइंटर के साथ रिटर्न एड्रेस को ओवरराइट कर दिया है <code>char c[12]</code>, जिसमें अब हमलावर द्वारा प्रदान किया गया डेटा सम्मलित है। एक वास्तविक स्टैक बफर ओवरफ्लो में ए की स्ट्रिंग का शोषण प्लेटफॉर्म और वांछित फ़ंक्शन के लिए उपयुक्त [[ app ]] होगा। यदि इस कार्यक्रम में विशेष विशेषाधिकार थे (उदाहरण के लिए सुपरयुजर के रूप में चलने के लिए सेटयूड बिट सेट), तो हमलावर इस भेद्यता का उपयोग प्रभावित मशीन पर [[ सुपर उपयोगकर्ता ]] विशेषाधिकार प्राप्त करने के लिए कर सकता है।<ref name="aleph1"/> | ||
हमलावर कुछ बगों का लाभ उठाने के लिए आंतरिक चर मानों को भी संशोधित कर सकता है। | |||
इस उदाहरण के साथ: | इस उदाहरण के साथ: | ||
<syntaxhighlight lang=c> | <syntaxhighlight lang=c> | ||
Line 81: | Line 82: | ||
== मंच से संबंधित मतभेद == | == मंच से संबंधित मतभेद == | ||
कई प्लेटफार्मों में कॉल स्टैक के उनके कार्यान्वयन में सूक्ष्म अंतर होते हैं जो स्टैक बफर ओवरफ्लो एक्सप्लॉइट के काम करने के | कई प्लेटफार्मों में कॉल स्टैक के उनके कार्यान्वयन में सूक्ष्म अंतर होते हैं जो स्टैक बफर ओवरफ्लो एक्सप्लॉइट के काम करने के विधि को प्रभावित कर सकते हैं। कुछ मशीन आर्किटेक्चर कॉल स्टैक के शीर्ष-स्तरीय रिटर्न एड्रेस को एक रजिस्टर में स्टोर करते हैं। इसका मतलब यह है कि किसी भी अधिलेखित वापसी पते का उपयोग तब तक नहीं किया जाएगा जब तक कि बाद में कॉल स्टैक को खोल नहीं दिया जाता। मशीन-विशिष्ट विवरण का एक और उदाहरण जो शोषण तकनीकों की पसंद को प्रभावित कर सकता है, वह तथ्य यह है कि अधिकांश [[ जोखिम ]]-शैली मशीन आर्किटेक्चर स्मृति तक असंरेखित पहुंच की अनुमति नहीं देंगे।<ref name="prl">{{cite web |author=pr1 |title=स्पार्क बफर ओवरफ्लो कमजोरियों का शोषण|url=http://www.ouah.org/UNF-sparc-overflow.html}}</ref> मशीन ऑपकोड के लिए एक निश्चित लंबाई के साथ संयुक्त, यह मशीन सीमा स्टैक पर कूदने की तकनीक को लागू करना लगभग असंभव बना सकती है (एक अपवाद के साथ जब प्रोग्राम में वास्तव में स्टैक रजिस्टर पर स्पष्ट रूप से कूदने के लिए असंभावित कोड होता है)।<ref name="curious1">{{cite journal |author=Curious |title=रिवर्स इंजीनियरिंग - जीडीबी के साथ मैक ओएस एक्स पर पावरपीसी क्रैकिंग|journal=[[Phrack]] |volume=11 |issue=63 |pages=16 |date=2005-01-08 |url=http://www.phrack.org/issues.html?issue=63&id=16#article}}</ref><ref name="feeb">{{cite report |last1=Sovarel |first1=Ana Nora |last2=Evans |first2=David |last3=Paul |first3=Nathanael |title=Where's the FEEB? The Effectiveness of Instruction Set Randomization |url=http://www.cs.virginia.edu/feeb/paper/}}</ref> | ||
=== ढेर जो बड़े होते हैं === | === ढेर जो बड़े होते हैं === | ||
स्टैक बफर ओवरफ्लो के विषय के भीतर, | स्टैक बफर ओवरफ्लो के विषय के भीतर, अधिकांशतः चर्चा की जाने वाली लेकिन दुर्लभ रूप से देखी जाने वाली वास्तुकला वह है जिसमें स्टैक विपरीत दिशा में बढ़ता है। आर्किटेक्चर में यह बदलाव अधिकांशतः स्टैक बफर ओवरफ्लो समस्या के समाधान के रूप में सुझाया जाता है क्योंकि स्टैक बफर का कोई भी ओवरफ्लो जो एक ही स्टैक फ्रेम के भीतर होता है, रिटर्न पॉइंटर को ओवरराइट नहीं कर सकता है। चूंकि , पिछले स्टैक फ्रेम से बफर में होने वाला कोई भी ओवरफ्लो अभी भी रिटर्न पॉइंटर को ओवरराइट करेगा और बग के दुर्भावनापूर्ण शोषण की अनुमति देगा।<ref name="zhodiac">{{cite journal |author=Zhodiac |title=एचपी-यूएक्स (पीए-आरआईएससी 1.1) ओवरफ्लो करता है|journal=[[Phrack]] |volume=11 |issue=58 |pages=11 |date=2001-12-28 |url=http://www.phrack.org/issues.html?issue=58&id=11}}</ref> उदाहरण के लिए, ऊपर दिए गए उदाहरण में, रिटर्न पॉइंटर for <code>foo</code> अधिलेखित नहीं किया जाएगा क्योंकि ओवरफ्लो वास्तव में स्टैक फ्रेम के भीतर होता है <code>memcpy</code>. चूंकि , क्योंकि बफर जो कॉल के दौरान बहता है <code>memcpy</code> पिछले स्टैक फ़्रेम में रहता है, जिसके लिए रिटर्न पॉइंटर <code>memcpy</code> बफर की समानता में संख्यात्मक रूप से अधिक मेमोरी एड्रेस होगा। इसका मतलब यह है कि रिटर्न पॉइंटर के अतिरिक्त <code>foo</code> ओवरराइट किया जा रहा है, के लिए रिटर्न पॉइंटर <code>memcpy</code> अधिलेखित हो जाएगा। अधिक से अधिक, इसका मतलब यह है कि स्टैक को विपरीत दिशा में बढ़ने से कुछ विवरण बदल जाएंगे कि कैसे स्टैक बफर ओवरफ्लो शोषक हैं, लेकिन यह शोषक बगों की संख्या को महत्वपूर्ण रूप से कम नहीं करेगा।{{Citation needed|date=July 2022}} | ||
== सुरक्षा योजनाएँ == | == सुरक्षा योजनाएँ == | ||
{{Main| | {{Main|बफर ओवरफ्लो सुरक्षा}} | ||
पिछले कुछ वर्षों में, दुर्भावनापूर्ण स्टैक बफर ओवरफ़्लो शोषण को रोकने के लिए कई [[नियंत्रण-प्रवाह अखंडता]] योजनाएं विकसित की गई हैं। इन्हें | पिछले कुछ वर्षों में, दुर्भावनापूर्ण स्टैक बफर ओवरफ़्लो शोषण को रोकने के लिए कई [[नियंत्रण-प्रवाह अखंडता]] योजनाएं विकसित की गई हैं। इन्हें सामान्यतः तीन श्रेणियों में वर्गीकृत किया जा सकता है: | ||
* पता लगाएं कि एक स्टैक बफर ओवरफ्लो हुआ है और इस प्रकार [[निर्देश सूचक]] को दुर्भावनापूर्ण कोड पर पुनर्निर्देशित करने से रोकता है। | * पता लगाएं कि एक स्टैक बफर ओवरफ्लो हुआ है और इस प्रकार [[निर्देश सूचक]] को दुर्भावनापूर्ण कोड पर पुनर्निर्देशित करने से रोकता है। | ||
Line 96: | Line 97: | ||
=== स्टैक कैनरी === | === स्टैक कैनरी === | ||
{{Further| | {{Further|कैनरी मूल्य}} | ||
स्टैक कैनरी, जिसका नाम एनिमल सेंटिनल | स्टैक कैनरी, जिसका नाम एनिमल सेंटिनल ऐतिहासिक उदाहरणों के अनुरूप रखा गया है, का उपयोग दुर्भावनापूर्ण कोड के निष्पादन से पहले स्टैक बफर ओवरफ़्लो का पता लगाने के लिए किया जाता है। यह विधि एक छोटे पूर्णांक को रखकर काम करती है, जिसका मान स्टैक रिटर्न पॉइंटर से ठीक पहले मेमोरी में प्रोग्राम स्टार्ट पर बेतरतीब ढंग से चुना जाता है। अधिकांश बफ़र अतिप्रवाह स्मृति को निम्न से उच्च स्मृति पतों पर अधिलेखित करते हैं, इसलिए रिटर्न पॉइंटर को अधिलेखित करने के लिए (और इस प्रकार प्रक्रिया को नियंत्रित करते हैं) कैनरी मान को भी अधिलेखित किया जाना चाहिए। स्टैक पर रिटर्न पॉइंटर का उपयोग करने से पहले यह सुनिश्चित करने के लिए यह मान चेक किया गया है कि यह नहीं बदला है।<ref name="dowd"/>यह तकनीक स्टैक बफ़र ओवरफ़्लो का दोहन करने की कठिनाई को बहुत बढ़ा सकती है क्योंकि यह हमलावर को कुछ गैर-पारंपरिक माध्यमों जैसे स्टैक पर अन्य महत्वपूर्ण चरों को दूषित करने के लिए निर्देश सूचक का नियंत्रण प्राप्त करने के लिए मजबूर करती है।<ref name="dowd"/> | ||
=== गैर-निष्पादन योग्य ढेर === | === गैर-निष्पादन योग्य ढेर === | ||
{{Main| | {{Main|निष्पादन योग्य अंतरिक्ष सुरक्षा}} | ||
स्टैक बफर अतिप्रवाह शोषण को रोकने के लिए एक अन्य दृष्टिकोण स्टैक मेमोरी क्षेत्र पर एक मेमोरी नीति लागू करना है जो स्टैक से निष्पादन की अनुमति नहीं देता है (W^X, XOR एक्सक्यूट लिखें)। इसका | |||
स्टैक बफर अतिप्रवाह शोषण को रोकने के लिए एक अन्य दृष्टिकोण स्टैक मेमोरी क्षेत्र पर एक मेमोरी नीति लागू करना है जो स्टैक से निष्पादन की अनुमति नहीं देता है (W^X, XOR एक्सक्यूट लिखें)। इसका अर्थ है कि स्टैक से शेलकोड को निष्पादित करने के लिए एक हमलावर को या तो मेमोरी से निष्पादन सुरक्षा को अक्षम करने का विधि ढूँढना होगा, या अपने शेलकोड पेलोड को मेमोरी के गैर-संरक्षित क्षेत्र में रखने का विधि ढूँढना होगा। यह विधि अब अधिक लोकप्रिय हो रही है कि अधिकांश डेस्कटॉप प्रोसेसर में नो-एक्ज़ीक्यूट फ़्लैग के लिए हार्डवेयर समर्थन उपलब्ध है। | |||
जबकि यह विधि कैनोनिकल स्टैक स्मैशिंग शोषण को रोकती है, स्टैक ओवरफ्लो का अन्य विधि से शोषण किया जा सकता है। सबसे पहले, ढेर जैसे असुरक्षित मेमोरी क्षेत्रों में शेलकोड को स्टोर करने के विधि ढूँढना सामान्य है, और इसलिए शोषण के विधि में बहुत कम बदलाव की आवश्यकता है।<ref name="syngress1">{{cite book |last1=Foster |first1=James C. |last2=Osipov |first2=Vitaly |last3=Bhalla |first3=Nish |last4=Heinen |first4=Niels |title=Buffer Overflow Attacks: Detect, Exploit, Prevent |publisher=Syngress Publishing, Inc. |year=2005 |location=United States of America |url=http://apossum.alfaspace.net/eng/Syngress.Buffer.Overflow.Attacks.Dec.2004.ISBN1932266674.pdf |isbn=1-932266-67-4}}</ref> | |||
एक अन्य हमला शेलकोड निर्माण के लिए तथाकथित [[रिटर्न-टू-लिबक हमला]] विधि है। इस हमले में दुर्भावनापूर्ण पेलोड स्टैक को शेलकोड के साथ नहीं, बल्कि एक उचित कॉल स्टैक के साथ लोड करेगा, जिससे निष्पादन मानक लाइब्रेरी कॉल की एक श्रृंखला के लिए किया जा सके, सामान्यतः मेमोरी निष्पादन सुरक्षा को अक्षम करने और शेलकोड को सामान्य रूप से चलाने की अनुमति देने के प्रभाव से।<ref name="nergal">{{cite journal |author=Nergal |title=The advanced return-into-lib(c) exploits: PaX case study |journal=[[Phrack]] |volume=11 |issue=58 |pages=4 |date=2001-12-28 |url=http://www.phrack.org/issues.html?issue=58&id=4#article}}</ref> यह काम करता है क्योंकि निष्पादन वास्तव में कभी भी स्टैक के लिए वैक्टर नहीं होता है। | |||
रिटर्न-टू-लिबक का एक संस्करण [[ वापसी-उन्मुख प्रोग्रामिंग | वापसी-उन्मुख प्रोग्रामिंग]] (आरओपी) है, जो रिटर्न पतों की एक श्रृंखला सेट करता है, जिनमें से प्रत्येक उपस्थित प्रोग्राम कोड या प्रणाली लाइब्रेरी के भीतर चेरी-चुने हुए मशीन निर्देशों के एक छोटे अनुक्रम को निष्पादित करता है, अनुक्रम जो वापसी के साथ समाप्त होता है। ये तथाकथित गैजेट लौटने से पहले कुछ सरल रजिस्टर हेरफेर या इसी तरह के निष्पादन को पूरा करते हैं, और उन्हें एक साथ स्ट्रिंग करने से हमलावर के सिरों को प्राप्त होता है। रिटर्नलेस रिटर्न-ओरिएंटेड प्रोग्रामिंग का उपयोग निर्देशों या निर्देशों के समूह का उपयोग करके भी संभव है जो रिटर्न निर्देश की तरह व्यवहार करते हैं।<ref>{{Cite book | doi = 10.1145/1866307.1866370| chapter = Return-Oriented Programming without Returns| title = Proceedings of the 17th ACM conference on Computer and communications security - CCS '10| pages = 559–572| date=October 2010 | last1 = Checkoway | first1 = S. | last2 = Davi | first2 = L. | last3 = Dmitrienko | first3 = A. | last4 = Sadeghi | first4 = A. R. | last5 = Shacham | first5 = H. | last6 = Winandy | first6 = M. | isbn = 978-1-4503-0245-6| s2cid = 207182734}}</ref> | |||
===यादृच्छिकीकरण=== | ===यादृच्छिकीकरण=== | ||
कोड को डेटा से अलग करने के | कोड को डेटा से अलग करने के अतिरिक्त , एक अन्य न्यूनीकरण तकनीक निष्पादन कार्यक्रम के मेमोरी स्पेस में यादृच्छिककरण का परिचय देना है। चूंकि हमलावर को यह निर्धारित करने की आवश्यकता होती है कि उपयोग किए जा सकने वाले निष्पादन योग्य कोड कहाँ रहता है, या तो एक निष्पादन योग्य पेलोड प्रदान किया जाता है (एक निष्पादन योग्य स्टैक के साथ) या कोड पुन: उपयोग जैसे कि ret2libc या रिटर्न-ओरिएंटेड प्रोग्रामिंग (ROP) का उपयोग करके बनाया गया है। एक अवधारणा के रूप में मेमोरी लेआउट को यादृच्छिक बनाना, हमलावर को यह जानने से रोकेगा कि कोई कोड कहां है। चूँकि , कार्यान्वयन सामान्यतः सब कुछ यादृच्छिक नहीं करेगा; सामान्यतः निष्पादन योग्य ही एक निश्चित पते पर लोड होता है और इसलिए जब [[ASLR]] (एड्रेस स्पेस लेआउट रेंडमाइजेशन) को एक गैर-निष्पादन योग्य स्टैक के साथ जोड़ा जाता है, तब भी हमलावर मेमोरी के इस निश्चित क्षेत्र का उपयोग कर सकता है। इसलिए, सभी कार्यक्रमों को स्थिति-स्वतंत्र कोड स्थिति-स्वतंत्र निष्पादन योग्य (स्थिति-स्वतंत्र निष्पादन योग्य) के साथ संकलित किया जाना चाहिए, जिससे स्मृति के इस क्षेत्र को भी यादृच्छिक बनाया जा सके। रैंडमाइजेशन की एन्ट्रापी कार्यान्वयन से कार्यान्वयन तक भिन्न होती है और एक कम पर्याप्त एन्ट्रापी अपने आप में एक समस्या हो सकती है जो मेमोरी स्पेस को यादृच्छिक रूप से मजबूर करने के स्थितियों में एक समस्या हो सकती है। | ||
=== बायपास काउंटरमेशर्स === | === बायपास काउंटरमेशर्स === | ||
पिछले न्यूनीकरण शोषण के कदमों को कठिन बना देते हैं। लेकिन | पिछले न्यूनीकरण शोषण के कदमों को कठिन बना देते हैं। लेकिन यदि कुछ भेद्यताएं उपस्थित हैं या कुछ शर्तों को पूरा किया जाता है तो स्टैक बफर ओवरफ्लो का लाभ उठाना अभी भी संभव है। | ||
==== स्टैक कैनरी बाईपास ==== | ==== स्टैक कैनरी बाईपास ==== | ||
===== [[प्रारूप स्ट्रिंग भेद्यता]] शोषण के साथ सूचना रिसाव ===== | ===== [[प्रारूप स्ट्रिंग भेद्यता]] शोषण के साथ सूचना रिसाव ===== | ||
एक हमलावर कमजोर कार्यक्रम में स्मृति स्थानों को प्रकट करने के लिए स्वरूप स्ट्रिंग भेद्यता का | एक हमलावर कमजोर कार्यक्रम में स्मृति स्थानों को प्रकट करने के लिए स्वरूप स्ट्रिंग भेद्यता का लाभ उठाने में सक्षम है।<ref>{{Cite journal |last1=Butt |first1=Muhammad Arif |last2=Ajmal |first2=Zarafshan |last3=Khan |first3=Zafar Iqbal |last4=Idrees |first4=Muhammad |last5=Javed |first5=Yasir |date=January 2022 |title=बफर ओवरफ्लो शमन तकनीकों को बायपास करने का एक गहन सर्वेक्षण|journal=Applied Sciences |language=en |volume=12 |issue=26 |pages=6702 |doi=10.3390/app12136702 |issn=2076-3417|doi-access=free }}</ref> | ||
==== गैर निष्पादन योग्य स्टैक बायपास ==== | ==== गैर निष्पादन योग्य स्टैक बायपास ==== | ||
जब [[डेटा निष्पादन प्रतिबंध]] को स्टैक तक किसी भी निष्पादन पहुंच को प्रतिबंधित करने के लिए सक्षम किया जाता है, तो हमलावर अभी भी ओवरराइट किए गए रिटर्न एड्रेस (निर्देश सूचक) का उपयोग [[ कोड खंड ]] में डेटा को इंगित करने के लिए कर सकता है ({{mono|.text}} लिनक्स पर) या प्रोग्राम के हर दूसरे निष्पादन योग्य खंड। लक्ष्य | जब [[डेटा निष्पादन प्रतिबंध]] को स्टैक तक किसी भी निष्पादन पहुंच को प्रतिबंधित करने के लिए सक्षम किया जाता है, तो हमलावर अभी भी ओवरराइट किए गए रिटर्न एड्रेस (निर्देश सूचक) का उपयोग [[ कोड खंड ]] में डेटा को इंगित करने के लिए कर सकता है ({{mono|.text}} लिनक्स पर) या प्रोग्राम के हर दूसरे निष्पादन योग्य खंड। लक्ष्य उपस्थित कोड का पुन: उपयोग करना है।<ref name=":0">{{Cite journal |last1=Butt |first1=Muhammad Arif |last2=Ajmal |first2=Zarafshan |last3=Khan |first3=Zafar Iqbal |last4=Idrees |first4=Muhammad |last5=Javed |first5=Yasir |date=January 2022 |title=बफर ओवरफ्लो शमन तकनीकों को बायपास करने का एक गहन सर्वेक्षण|journal=Applied Sciences |language=en |volume=12 |issue=13 |pages=12–13 |doi=10.3390/app12136702 |issn=2076-3417|doi-access=free }}</ref> | ||
===== रोप चेन ===== | ===== रोप चेन ===== | ||
प्रोग्राम के रिटर्न इंस्ट्रक्शन (x86 में रिट) से थोड़ा पहले रिटर्न पॉइंटर को ओवरराइट करना | प्रोग्राम के रिटर्न इंस्ट्रक्शन (x86 में रिट) से थोड़ा पहले रिटर्न पॉइंटर को ओवरराइट करना सम्मलित है। नए रिटर्न पॉइंटर और रिटर्न इंस्ट्रक्शन के बीच के निर्देशों को निष्पादित किया जाएगा और रिटर्न इंस्ट्रक्शन शोषक द्वारा नियंत्रित पेलोड पर वापस आ जाएगा।<ref name=":0" />{{clarify|date=September 2022}} | ||
===== जोप चैन ===== | ===== जोप चैन ===== | ||
जंप ओरिएंटेड प्रोग्रामिंग एक ऐसी तकनीक है जो रिट निर्देश के | जंप ओरिएंटेड प्रोग्रामिंग एक ऐसी तकनीक है जो रिट निर्देश के अतिरिक्त कोड का पुन: उपयोग करने के लिए जंप निर्देशों का उपयोग करती है।<ref>{{Cite book |url=https://www.dunod.com/sciences-techniques/securite-materielle-systemes-vulnerabilite-processeurs-et-techniques-d |title=Sécurité matérielle des systèmes |date=2022-09-03 |language=fr}}</ref> | ||
==== रैंडमाइजेशन बायपास ==== | ==== रैंडमाइजेशन बायपास ==== | ||
64-बिट | 64-बिट प्रणाली पर ASLR प्राप्ति की एक सीमा यह है कि यह स्मृति प्रकटीकरण और सूचना रिसाव हमलों के प्रति संवेदनशील है। हमलावर सूचना रिसाव हमले का उपयोग करके एकल फ़ंक्शन पते का खुलासा करके ROP लॉन्च कर सकता है। निम्नलिखित खंड ASLR सुरक्षा को तोड़ने के लिए समान उपस्थित रणनीति का वर्णन करता है।<ref>{{Cite journal |last1=Butt |first1=Muhammad Arif |last2=Ajmal |first2=Zarafshan |last3=Khan |first3=Zafar Iqbal |last4=Idrees |first4=Muhammad |last5=Javed |first5=Yasir |date=January 2022 |title=बफर ओवरफ्लो शमन तकनीकों को बायपास करने का एक गहन सर्वेक्षण|journal=Applied Sciences |language=en |volume=12 |issue=16 |pages=6702 |doi=10.3390/app12136702 |issn=2076-3417|doi-access=free }}</ref> | ||
== उल्लेखनीय उदाहरण == | == उल्लेखनीय उदाहरण == | ||
* 1988 में [[मॉरिस कीड़ा]] [[यूनिक्स]] [[फिंगर प्रोटोकॉल]] सर्वर में स्टैक बफर ओवरफ्लो का दोहन करके आंशिक रूप से फैल गया। [http://www.ee.ryerson.ca/~elf/hack/iworm.html] | * 1988 में [[मॉरिस कीड़ा]] [[यूनिक्स]] [[फिंगर प्रोटोकॉल]] सर्वर में स्टैक बफर ओवरफ्लो का दोहन करके आंशिक रूप से फैल गया। [http://www.ee.ryerson.ca/~elf/hack/iworm.html] | ||
* 2003 में [[SQL Slammer]] | * 2003 में [[SQL Slammer|SQL स्लैमर]] माइक्रोसॉफ्ट के SQL सर्वर में स्टैक बफर ओवरफ्लो का शोषण करके फैल गया। [https://www.wired.com/wired/archive/11.07/slammer.html] | ||
* 2003 में [[माइक्रोसॉफ्ट]] [[वितरित घटक वस्तु मॉडल]] सर्विस में स्टैक बफर ओवरफ्लो का | * 2003 में [[माइक्रोसॉफ्ट]] [[वितरित घटक वस्तु मॉडल]] सर्विस में स्टैक बफर ओवरफ्लो का लाभ उठाकर [[विस्फ़ोटक कीड़ा]] फैल गया। | ||
* [[इंटरनेट सुरक्षा प्रणाली]] ब्लैकआईसीई डेस्कटॉप एजेंट में स्टैक बफर ओवरफ्लो का दोहन करके 2004 में [[मजाकिया कीड़ा]] फैल गया। nweaver/login_witty.txt] | * [[इंटरनेट सुरक्षा प्रणाली]] ब्लैकआईसीई डेस्कटॉप एजेंट में स्टैक बफर ओवरफ्लो का दोहन करके 2004 में [[मजाकिया कीड़ा]] फैल गया। nweaver/login_witty.txt] | ||
* [[Wii]] के कुछ उदाहरण हैं जो | * [[Wii]] के कुछ उदाहरण हैं जो इच्छानुसार कोड को एक असंशोधित प्रणाली पर चलाने की अनुमति देते हैं। द ट्वाइलाइट हैक जिसमें द लीजेंड ऑफ ज़ेल्डा: ट्वाइलाइट प्रिंसेस में मुख्य पात्र के घोड़े को एक लंबा नाम देना सम्मलित है,<ref>{{Cite web|url=http://wiibrew.org/wiki/Twilight_Hack|title=गोधूलि हैक - WiiBrew|website=wiibrew.org|language=en|access-date=2018-01-18}}</ref> और सुपर स्मैश ब्रदर्स ब्रॉल के लिए स्मैश स्टैक जिसमें विशेष रूप से तैयार फ़ाइल को इन-गेम स्तर के संपादक में लोड करने के लिए एसडी कार्ड का उपयोग करना सम्मलित है। चूंकि दोनों का उपयोग किसी भी इच्छानुसार कोड को निष्पादित करने के लिए किया जा सकता है, बाद वाले का उपयोग अधिकांशतः ब्रॉल को केवल मॉड (वीडियो गेमिंग) के साथ पुनः लोड करने के लिए किया जाता है।<ref>{{Cite web|url=http://wiibrew.org/wiki/Smash_Stack|title=स्मैश स्टैक - WiiBrew|website=wiibrew.org|language=en|access-date=2018-01-18}}</ref> | ||
== यह भी देखें == | == यह भी देखें == | ||
* [[ExecShield]] | * [[ExecShield|एक्सेक्यूटिव शील्ड]] | ||
* [[ढेर अतिप्रवाह]] | * [[ढेर अतिप्रवाह]] | ||
* [[पूर्णांक अतिप्रवाह]] | * [[पूर्णांक अतिप्रवाह]] |
Revision as of 09:46, 24 May 2023
सॉफ़्टवेयर में, स्टैक बफ़र ओवरफ़्लो या स्टैक बफ़र ओवररन तब होता है जब कोई प्रोग्राम इच्छित डेटा संरचना के बाहर प्रोग्राम के कॉल स्टैक पर स्मृति पते पर लिखता है, जो सामान्यतः एक निश्चित-लंबाई डेटा बफर होता है।[1][2] स्टैक बफ़र अधिकता बग तब होते हैं जब कोई प्रोग्राम स्टैक पर स्थित बफर को वास्तव में उस बफर के लिए आवंटित डेटा से अधिक डेटा लिखता है। यह लगभग हमेशा स्टैक पर आसन्न डेटा के भ्रष्टाचार का परिणाम होता है, और ऐसे मामलों में जहां अतिप्रवाह गलती से प्रारंभ हो गया था, अधिकांशतः प्रोग्राम को क्रैश या गलत विधि से संचालित करने का कारण बनता है। स्टैक बफर ओवरफ्लो एक प्रकार का अधिक सामान्य प्रोग्रामिंग खराबी है जिसे बफर ओवरफ्लो (या बफर ओवररन) के रूप में जाना जाता है।[1]स्टैक पर एक बफ़र को ओवरफ़िल करने से हीप पर एक बफ़र को ओवरफ़िल करने की समानता में प्रोग्राम के निष्पादन को पटरी से उतारने की संभावना अधिक होती है क्योंकि स्टैक में सभी सक्रिय फ़ंक्शन कॉल के लिए रिटर्न एड्रेस होते हैं।
स्टैक स्मैशिंग के रूप में जाने जाने वाले हमले के हिस्से के रूप में एक स्टैक बफर ओवरफ़्लो जानबूझकर हो सकता है। यदि प्रभावित प्रोग्राम विशेष विशेषाधिकारों के साथ चल रहा है, या अविश्वसनीय नेटवर्क होस्ट (जैसे वेब सर्वर ) से डेटा स्वीकार करता है तो बग एक संभावित सुरक्षा भेद्यता है। यदि स्टैक बफ़र एक अविश्वसनीय उपयोगकर्ता द्वारा प्रदान किए गए डेटा से भरा हुआ है, तो वह उपयोगकर्ता स्टैक को इस तरह से दूषित कर सकता है जैसे निष्पादन योग्य कोड को रनिंग प्रोग्राम में इंजेक्ट कर सकता है और प्रक्रिया को नियंत्रित कर सकता है। यह हैकर (कंप्यूटर सुरक्षा) के लिए कंप्यूटर पर अनधिकृत पहुंच प्राप्त करने के सबसे पुराने और अधिक विश्वसनीय तरीकों में से एक है।[3][4][5]
स्टैक बफर ओवरफ्लो का शोषण
एक्सप्लॉइट (कंप्यूटर सुरक्षा) के लिए एक स्टैक-आधारित बफर ओवरफ़्लो के लिए कैननिकल विधि हमलावर-नियंत्रित डेटा (सामान्यतः स्टैक पर ही) के सूचक के साथ फ़ंक्शन रिटर्न एड्रेस को ओवरराइट करना है।[3][6] इसके द्वारा दर्शाया गया है strcpy()
निम्नलिखित उदाहरण में:
#include <string.h>
void foo(char *bar)
{
char c[12];
strcpy(c, bar); // no bounds checking
}
int main(int argc, char **argv)
{
foo(argv[1]);
return 0;
}
यह कोड कमांड लाइन से तर्क लेता है और इसे स्थानीय स्टैक चर में कॉपी करता है c
. यह 12 वर्णों से छोटे कमांड-लाइन तर्कों के लिए ठीक काम करता है (जैसा कि नीचे चित्र B में देखा जा सकता है)। 11 वर्णों से बड़े किसी भी तर्क के परिणामस्वरूप ढेर का भ्रष्टाचार होगा। (सुरक्षित वर्णों की अधिकतम संख्या यहाँ बफ़र के आकार से एक कम है क्योंकि C प्रोग्रामिंग भाषा में, स्ट्रिंग्स को एक शून्य बाइट वर्ण द्वारा समाप्त किया जाता है। एक बारह-वर्ण इनपुट को स्टोर करने के लिए तेरह बाइट्स की आवश्यकता होती है, इनपुट के बाद प्रहरी शून्य बाइट द्वारा। शून्य बाइट तब एक स्मृति स्थान को अधिलेखित कर देता है जो बफर के अंत से एक बाइट है।)
कार्यक्रम ढेर हो गया foo()
विभिन्न इनपुट के साथ:
उपरोक्त आकृति C में, जब कमांड लाइन पर 11 बाइट्स से बड़ा तर्क दिया जाता है foo()
स्थानीय स्टैक डेटा, सहेजे गए फ़्रेम पॉइंटर और सबसे महत्वपूर्ण रूप से रिटर्न एड्रेस को ओवरराइट करता है। कब foo()
रिटर्न यह स्टैक से वापसी पता पॉप करता है और उस पते पर कूदता है (यानी उस पते से निर्देश निष्पादित करना प्रारंभ करता है)। इस प्रकार, हमलावर ने स्टैक बफर के पॉइंटर के साथ रिटर्न एड्रेस को ओवरराइट कर दिया है char c[12]
, जिसमें अब हमलावर द्वारा प्रदान किया गया डेटा सम्मलित है। एक वास्तविक स्टैक बफर ओवरफ्लो में ए की स्ट्रिंग का शोषण प्लेटफॉर्म और वांछित फ़ंक्शन के लिए उपयुक्त app होगा। यदि इस कार्यक्रम में विशेष विशेषाधिकार थे (उदाहरण के लिए सुपरयुजर के रूप में चलने के लिए सेटयूड बिट सेट), तो हमलावर इस भेद्यता का उपयोग प्रभावित मशीन पर सुपर उपयोगकर्ता विशेषाधिकार प्राप्त करने के लिए कर सकता है।[3]
हमलावर कुछ बगों का लाभ उठाने के लिए आंतरिक चर मानों को भी संशोधित कर सकता है।
इस उदाहरण के साथ:
#include <string.h>
#include <stdio.h>
void foo(char *bar)
{
float My_Float = 10.5; // Addr = 0x0023FF4C
char c[28]; // Addr = 0x0023FF30
// Will print 10.500000
printf("My Float value = %f\n", My_Float);
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Memory map:
@ : c allocated memory
# : My_Float allocated memory
*c *My_Float
0x0023FF30 0x0023FF4C
| |
@@@@@@@@@@@@@@@@@@@@@@@@@@@@#####
foo("my string is too long !!!!! XXXXX");
memcpy will put 0x1010C042 (little endian) in My_Float value.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*/
memcpy(c, bar, strlen(bar)); // no bounds checking...
// Will print 96.031372
printf("My Float value = %f\n", My_Float);
}
int main(int argc, char **argv)
{
foo("my string is too long !!!!! \x10\x10\xc0\x42");
return 0;
}
मंच से संबंधित मतभेद
कई प्लेटफार्मों में कॉल स्टैक के उनके कार्यान्वयन में सूक्ष्म अंतर होते हैं जो स्टैक बफर ओवरफ्लो एक्सप्लॉइट के काम करने के विधि को प्रभावित कर सकते हैं। कुछ मशीन आर्किटेक्चर कॉल स्टैक के शीर्ष-स्तरीय रिटर्न एड्रेस को एक रजिस्टर में स्टोर करते हैं। इसका मतलब यह है कि किसी भी अधिलेखित वापसी पते का उपयोग तब तक नहीं किया जाएगा जब तक कि बाद में कॉल स्टैक को खोल नहीं दिया जाता। मशीन-विशिष्ट विवरण का एक और उदाहरण जो शोषण तकनीकों की पसंद को प्रभावित कर सकता है, वह तथ्य यह है कि अधिकांश जोखिम -शैली मशीन आर्किटेक्चर स्मृति तक असंरेखित पहुंच की अनुमति नहीं देंगे।[7] मशीन ऑपकोड के लिए एक निश्चित लंबाई के साथ संयुक्त, यह मशीन सीमा स्टैक पर कूदने की तकनीक को लागू करना लगभग असंभव बना सकती है (एक अपवाद के साथ जब प्रोग्राम में वास्तव में स्टैक रजिस्टर पर स्पष्ट रूप से कूदने के लिए असंभावित कोड होता है)।[8][9]
ढेर जो बड़े होते हैं
स्टैक बफर ओवरफ्लो के विषय के भीतर, अधिकांशतः चर्चा की जाने वाली लेकिन दुर्लभ रूप से देखी जाने वाली वास्तुकला वह है जिसमें स्टैक विपरीत दिशा में बढ़ता है। आर्किटेक्चर में यह बदलाव अधिकांशतः स्टैक बफर ओवरफ्लो समस्या के समाधान के रूप में सुझाया जाता है क्योंकि स्टैक बफर का कोई भी ओवरफ्लो जो एक ही स्टैक फ्रेम के भीतर होता है, रिटर्न पॉइंटर को ओवरराइट नहीं कर सकता है। चूंकि , पिछले स्टैक फ्रेम से बफर में होने वाला कोई भी ओवरफ्लो अभी भी रिटर्न पॉइंटर को ओवरराइट करेगा और बग के दुर्भावनापूर्ण शोषण की अनुमति देगा।[10] उदाहरण के लिए, ऊपर दिए गए उदाहरण में, रिटर्न पॉइंटर for foo
अधिलेखित नहीं किया जाएगा क्योंकि ओवरफ्लो वास्तव में स्टैक फ्रेम के भीतर होता है memcpy
. चूंकि , क्योंकि बफर जो कॉल के दौरान बहता है memcpy
पिछले स्टैक फ़्रेम में रहता है, जिसके लिए रिटर्न पॉइंटर memcpy
बफर की समानता में संख्यात्मक रूप से अधिक मेमोरी एड्रेस होगा। इसका मतलब यह है कि रिटर्न पॉइंटर के अतिरिक्त foo
ओवरराइट किया जा रहा है, के लिए रिटर्न पॉइंटर memcpy
अधिलेखित हो जाएगा। अधिक से अधिक, इसका मतलब यह है कि स्टैक को विपरीत दिशा में बढ़ने से कुछ विवरण बदल जाएंगे कि कैसे स्टैक बफर ओवरफ्लो शोषक हैं, लेकिन यह शोषक बगों की संख्या को महत्वपूर्ण रूप से कम नहीं करेगा।[citation needed]
सुरक्षा योजनाएँ
पिछले कुछ वर्षों में, दुर्भावनापूर्ण स्टैक बफर ओवरफ़्लो शोषण को रोकने के लिए कई नियंत्रण-प्रवाह अखंडता योजनाएं विकसित की गई हैं। इन्हें सामान्यतः तीन श्रेणियों में वर्गीकृत किया जा सकता है:
- पता लगाएं कि एक स्टैक बफर ओवरफ्लो हुआ है और इस प्रकार निर्देश सूचक को दुर्भावनापूर्ण कोड पर पुनर्निर्देशित करने से रोकता है।
- सीधे स्टैक बफर ओवरफ्लो का पता लगाए बिना स्टैक से दुर्भावनापूर्ण कोड के निष्पादन को रोकें।
- मेमोरी स्पेस को ऐसे रेंडमाइज करें कि एक्जीक्यूटेबल कोड ढूंढना अविश्वसनीय हो जाए।
स्टैक कैनरी
स्टैक कैनरी, जिसका नाम एनिमल सेंटिनल ऐतिहासिक उदाहरणों के अनुरूप रखा गया है, का उपयोग दुर्भावनापूर्ण कोड के निष्पादन से पहले स्टैक बफर ओवरफ़्लो का पता लगाने के लिए किया जाता है। यह विधि एक छोटे पूर्णांक को रखकर काम करती है, जिसका मान स्टैक रिटर्न पॉइंटर से ठीक पहले मेमोरी में प्रोग्राम स्टार्ट पर बेतरतीब ढंग से चुना जाता है। अधिकांश बफ़र अतिप्रवाह स्मृति को निम्न से उच्च स्मृति पतों पर अधिलेखित करते हैं, इसलिए रिटर्न पॉइंटर को अधिलेखित करने के लिए (और इस प्रकार प्रक्रिया को नियंत्रित करते हैं) कैनरी मान को भी अधिलेखित किया जाना चाहिए। स्टैक पर रिटर्न पॉइंटर का उपयोग करने से पहले यह सुनिश्चित करने के लिए यह मान चेक किया गया है कि यह नहीं बदला है।[2]यह तकनीक स्टैक बफ़र ओवरफ़्लो का दोहन करने की कठिनाई को बहुत बढ़ा सकती है क्योंकि यह हमलावर को कुछ गैर-पारंपरिक माध्यमों जैसे स्टैक पर अन्य महत्वपूर्ण चरों को दूषित करने के लिए निर्देश सूचक का नियंत्रण प्राप्त करने के लिए मजबूर करती है।[2]
गैर-निष्पादन योग्य ढेर
स्टैक बफर अतिप्रवाह शोषण को रोकने के लिए एक अन्य दृष्टिकोण स्टैक मेमोरी क्षेत्र पर एक मेमोरी नीति लागू करना है जो स्टैक से निष्पादन की अनुमति नहीं देता है (W^X, XOR एक्सक्यूट लिखें)। इसका अर्थ है कि स्टैक से शेलकोड को निष्पादित करने के लिए एक हमलावर को या तो मेमोरी से निष्पादन सुरक्षा को अक्षम करने का विधि ढूँढना होगा, या अपने शेलकोड पेलोड को मेमोरी के गैर-संरक्षित क्षेत्र में रखने का विधि ढूँढना होगा। यह विधि अब अधिक लोकप्रिय हो रही है कि अधिकांश डेस्कटॉप प्रोसेसर में नो-एक्ज़ीक्यूट फ़्लैग के लिए हार्डवेयर समर्थन उपलब्ध है।
जबकि यह विधि कैनोनिकल स्टैक स्मैशिंग शोषण को रोकती है, स्टैक ओवरफ्लो का अन्य विधि से शोषण किया जा सकता है। सबसे पहले, ढेर जैसे असुरक्षित मेमोरी क्षेत्रों में शेलकोड को स्टोर करने के विधि ढूँढना सामान्य है, और इसलिए शोषण के विधि में बहुत कम बदलाव की आवश्यकता है।[11]
एक अन्य हमला शेलकोड निर्माण के लिए तथाकथित रिटर्न-टू-लिबक हमला विधि है। इस हमले में दुर्भावनापूर्ण पेलोड स्टैक को शेलकोड के साथ नहीं, बल्कि एक उचित कॉल स्टैक के साथ लोड करेगा, जिससे निष्पादन मानक लाइब्रेरी कॉल की एक श्रृंखला के लिए किया जा सके, सामान्यतः मेमोरी निष्पादन सुरक्षा को अक्षम करने और शेलकोड को सामान्य रूप से चलाने की अनुमति देने के प्रभाव से।[12] यह काम करता है क्योंकि निष्पादन वास्तव में कभी भी स्टैक के लिए वैक्टर नहीं होता है।
रिटर्न-टू-लिबक का एक संस्करण वापसी-उन्मुख प्रोग्रामिंग (आरओपी) है, जो रिटर्न पतों की एक श्रृंखला सेट करता है, जिनमें से प्रत्येक उपस्थित प्रोग्राम कोड या प्रणाली लाइब्रेरी के भीतर चेरी-चुने हुए मशीन निर्देशों के एक छोटे अनुक्रम को निष्पादित करता है, अनुक्रम जो वापसी के साथ समाप्त होता है। ये तथाकथित गैजेट लौटने से पहले कुछ सरल रजिस्टर हेरफेर या इसी तरह के निष्पादन को पूरा करते हैं, और उन्हें एक साथ स्ट्रिंग करने से हमलावर के सिरों को प्राप्त होता है। रिटर्नलेस रिटर्न-ओरिएंटेड प्रोग्रामिंग का उपयोग निर्देशों या निर्देशों के समूह का उपयोग करके भी संभव है जो रिटर्न निर्देश की तरह व्यवहार करते हैं।[13]
यादृच्छिकीकरण
कोड को डेटा से अलग करने के अतिरिक्त , एक अन्य न्यूनीकरण तकनीक निष्पादन कार्यक्रम के मेमोरी स्पेस में यादृच्छिककरण का परिचय देना है। चूंकि हमलावर को यह निर्धारित करने की आवश्यकता होती है कि उपयोग किए जा सकने वाले निष्पादन योग्य कोड कहाँ रहता है, या तो एक निष्पादन योग्य पेलोड प्रदान किया जाता है (एक निष्पादन योग्य स्टैक के साथ) या कोड पुन: उपयोग जैसे कि ret2libc या रिटर्न-ओरिएंटेड प्रोग्रामिंग (ROP) का उपयोग करके बनाया गया है। एक अवधारणा के रूप में मेमोरी लेआउट को यादृच्छिक बनाना, हमलावर को यह जानने से रोकेगा कि कोई कोड कहां है। चूँकि , कार्यान्वयन सामान्यतः सब कुछ यादृच्छिक नहीं करेगा; सामान्यतः निष्पादन योग्य ही एक निश्चित पते पर लोड होता है और इसलिए जब ASLR (एड्रेस स्पेस लेआउट रेंडमाइजेशन) को एक गैर-निष्पादन योग्य स्टैक के साथ जोड़ा जाता है, तब भी हमलावर मेमोरी के इस निश्चित क्षेत्र का उपयोग कर सकता है। इसलिए, सभी कार्यक्रमों को स्थिति-स्वतंत्र कोड स्थिति-स्वतंत्र निष्पादन योग्य (स्थिति-स्वतंत्र निष्पादन योग्य) के साथ संकलित किया जाना चाहिए, जिससे स्मृति के इस क्षेत्र को भी यादृच्छिक बनाया जा सके। रैंडमाइजेशन की एन्ट्रापी कार्यान्वयन से कार्यान्वयन तक भिन्न होती है और एक कम पर्याप्त एन्ट्रापी अपने आप में एक समस्या हो सकती है जो मेमोरी स्पेस को यादृच्छिक रूप से मजबूर करने के स्थितियों में एक समस्या हो सकती है।
बायपास काउंटरमेशर्स
पिछले न्यूनीकरण शोषण के कदमों को कठिन बना देते हैं। लेकिन यदि कुछ भेद्यताएं उपस्थित हैं या कुछ शर्तों को पूरा किया जाता है तो स्टैक बफर ओवरफ्लो का लाभ उठाना अभी भी संभव है।
स्टैक कैनरी बाईपास
प्रारूप स्ट्रिंग भेद्यता शोषण के साथ सूचना रिसाव
एक हमलावर कमजोर कार्यक्रम में स्मृति स्थानों को प्रकट करने के लिए स्वरूप स्ट्रिंग भेद्यता का लाभ उठाने में सक्षम है।[14]
गैर निष्पादन योग्य स्टैक बायपास
जब डेटा निष्पादन प्रतिबंध को स्टैक तक किसी भी निष्पादन पहुंच को प्रतिबंधित करने के लिए सक्षम किया जाता है, तो हमलावर अभी भी ओवरराइट किए गए रिटर्न एड्रेस (निर्देश सूचक) का उपयोग कोड खंड में डेटा को इंगित करने के लिए कर सकता है (.text लिनक्स पर) या प्रोग्राम के हर दूसरे निष्पादन योग्य खंड। लक्ष्य उपस्थित कोड का पुन: उपयोग करना है।[15]
रोप चेन
प्रोग्राम के रिटर्न इंस्ट्रक्शन (x86 में रिट) से थोड़ा पहले रिटर्न पॉइंटर को ओवरराइट करना सम्मलित है। नए रिटर्न पॉइंटर और रिटर्न इंस्ट्रक्शन के बीच के निर्देशों को निष्पादित किया जाएगा और रिटर्न इंस्ट्रक्शन शोषक द्वारा नियंत्रित पेलोड पर वापस आ जाएगा।[15][clarification needed]
जोप चैन
जंप ओरिएंटेड प्रोग्रामिंग एक ऐसी तकनीक है जो रिट निर्देश के अतिरिक्त कोड का पुन: उपयोग करने के लिए जंप निर्देशों का उपयोग करती है।[16]
रैंडमाइजेशन बायपास
64-बिट प्रणाली पर ASLR प्राप्ति की एक सीमा यह है कि यह स्मृति प्रकटीकरण और सूचना रिसाव हमलों के प्रति संवेदनशील है। हमलावर सूचना रिसाव हमले का उपयोग करके एकल फ़ंक्शन पते का खुलासा करके ROP लॉन्च कर सकता है। निम्नलिखित खंड ASLR सुरक्षा को तोड़ने के लिए समान उपस्थित रणनीति का वर्णन करता है।[17]
उल्लेखनीय उदाहरण
- 1988 में मॉरिस कीड़ा यूनिक्स फिंगर प्रोटोकॉल सर्वर में स्टैक बफर ओवरफ्लो का दोहन करके आंशिक रूप से फैल गया। [1]
- 2003 में SQL स्लैमर माइक्रोसॉफ्ट के SQL सर्वर में स्टैक बफर ओवरफ्लो का शोषण करके फैल गया। [2]
- 2003 में माइक्रोसॉफ्ट वितरित घटक वस्तु मॉडल सर्विस में स्टैक बफर ओवरफ्लो का लाभ उठाकर विस्फ़ोटक कीड़ा फैल गया।
- इंटरनेट सुरक्षा प्रणाली ब्लैकआईसीई डेस्कटॉप एजेंट में स्टैक बफर ओवरफ्लो का दोहन करके 2004 में मजाकिया कीड़ा फैल गया। nweaver/login_witty.txt]
- Wii के कुछ उदाहरण हैं जो इच्छानुसार कोड को एक असंशोधित प्रणाली पर चलाने की अनुमति देते हैं। द ट्वाइलाइट हैक जिसमें द लीजेंड ऑफ ज़ेल्डा: ट्वाइलाइट प्रिंसेस में मुख्य पात्र के घोड़े को एक लंबा नाम देना सम्मलित है,[18] और सुपर स्मैश ब्रदर्स ब्रॉल के लिए स्मैश स्टैक जिसमें विशेष रूप से तैयार फ़ाइल को इन-गेम स्तर के संपादक में लोड करने के लिए एसडी कार्ड का उपयोग करना सम्मलित है। चूंकि दोनों का उपयोग किसी भी इच्छानुसार कोड को निष्पादित करने के लिए किया जा सकता है, बाद वाले का उपयोग अधिकांशतः ब्रॉल को केवल मॉड (वीडियो गेमिंग) के साथ पुनः लोड करने के लिए किया जाता है।[19]
यह भी देखें
- एक्सेक्यूटिव शील्ड
- ढेर अतिप्रवाह
- पूर्णांक अतिप्रवाह
- एनएक्स बिट - मेमोरी के क्षेत्रों के लिए नो-एक्ज़ीक्यूट बिट
- सुरक्षा-उन्नत लिनक्स
- स्टैक ओवरफ़्लो - जब स्टैक स्वयं ओवरफ्लो हो जाता है
- भंडारण उल्लंघन
संदर्भ
- ↑ 1.0 1.1 Fithen, William L.; Seacord, Robert (2007-03-27). "वीटी-एमबी। स्मृति सीमा का उल्लंघन". US CERT.
- ↑ 2.0 2.1 2.2 Dowd, Mark; McDonald, John; Schuh, Justin (November 2006). सॉफ्टवेयर सुरक्षा आकलन की कला. Addison Wesley. pp. 169–196. ISBN 0-321-44442-6.
- ↑ 3.0 3.1 3.2 Levy, Elias (1996-11-08). "आनंद और लाभ के लिए ढेर को नष्ट करना". Phrack. 7 (49): 14.
- ↑ Pincus, J.; Baker, B. (July–August 2004). "Beyond Stack Smashing: Recent Advances in Exploiting Buffer Overruns" (PDF). IEEE Security and Privacy Magazine. 2 (4): 20–27. doi:10.1109/MSP.2004.36. S2CID 6647392.
- ↑ Burebista. "स्टैक ओवरफ़्लो" (PDF). Archived from the original (PDF) on September 28, 2007.[dead link]
- ↑ Bertrand, Louis (2002). "OpenBSD: Fix the Bugs, Secure the System". MUSESS '02: McMaster University Software Engineering Symposium. Archived from the original on 2007-09-30.
- ↑ pr1. "स्पार्क बफर ओवरफ्लो कमजोरियों का शोषण".
- ↑ Curious (2005-01-08). "रिवर्स इंजीनियरिंग - जीडीबी के साथ मैक ओएस एक्स पर पावरपीसी क्रैकिंग". Phrack. 11 (63): 16.
- ↑ Sovarel, Ana Nora; Evans, David; Paul, Nathanael. Where's the FEEB? The Effectiveness of Instruction Set Randomization (Report).
- ↑ Zhodiac (2001-12-28). "एचपी-यूएक्स (पीए-आरआईएससी 1.1) ओवरफ्लो करता है". Phrack. 11 (58): 11.
- ↑ Foster, James C.; Osipov, Vitaly; Bhalla, Nish; Heinen, Niels (2005). Buffer Overflow Attacks: Detect, Exploit, Prevent (PDF). United States of America: Syngress Publishing, Inc. ISBN 1-932266-67-4.
- ↑ Nergal (2001-12-28). "The advanced return-into-lib(c) exploits: PaX case study". Phrack. 11 (58): 4.
- ↑ Checkoway, S.; Davi, L.; Dmitrienko, A.; Sadeghi, A. R.; Shacham, H.; Winandy, M. (October 2010). "Return-Oriented Programming without Returns". Proceedings of the 17th ACM conference on Computer and communications security - CCS '10. pp. 559–572. doi:10.1145/1866307.1866370. ISBN 978-1-4503-0245-6. S2CID 207182734.
- ↑ Butt, Muhammad Arif; Ajmal, Zarafshan; Khan, Zafar Iqbal; Idrees, Muhammad; Javed, Yasir (January 2022). "बफर ओवरफ्लो शमन तकनीकों को बायपास करने का एक गहन सर्वेक्षण". Applied Sciences (in English). 12 (26): 6702. doi:10.3390/app12136702. ISSN 2076-3417.
- ↑ 15.0 15.1 Butt, Muhammad Arif; Ajmal, Zarafshan; Khan, Zafar Iqbal; Idrees, Muhammad; Javed, Yasir (January 2022). "बफर ओवरफ्लो शमन तकनीकों को बायपास करने का एक गहन सर्वेक्षण". Applied Sciences (in English). 12 (13): 12–13. doi:10.3390/app12136702. ISSN 2076-3417.
- ↑ Sécurité matérielle des systèmes (in français). 2022-09-03.
- ↑ Butt, Muhammad Arif; Ajmal, Zarafshan; Khan, Zafar Iqbal; Idrees, Muhammad; Javed, Yasir (January 2022). "बफर ओवरफ्लो शमन तकनीकों को बायपास करने का एक गहन सर्वेक्षण". Applied Sciences (in English). 12 (16): 6702. doi:10.3390/app12136702. ISSN 2076-3417.
- ↑ "गोधूलि हैक - WiiBrew". wiibrew.org (in English). Retrieved 2018-01-18.
- ↑ "स्मैश स्टैक - WiiBrew". wiibrew.org (in English). Retrieved 2018-01-18.