निष्पादन योग्य स्पेस सुरक्षा: Difference between revisions

From Vigyanwiki
No edit summary
Line 1: Line 1:
{{Short description|Concept in computer security}}
{{Short description|Concept in computer security}}[[कंप्यूटर सुरक्षा]] में, निष्पादन योग्य-स्थान सुरक्षा कंप्यूटर मेमोरी क्षेत्रों को गैर-निष्पादन योग्य के रूप में चिह्नित करती है, जैसे कि इन क्षेत्रों में [[मशीन कोड]] को निष्पादित करने का प्रयास एक अपवाद हैंडलिंग का कारण होगा। यह NX बिट (नो-एक्ज़ीक्यूट बिट) जैसी हार्डवेयर सुविधाओं का उपयोग करता है, या कुछ मामलों में उन सुविधाओं का सॉफ़्टवेयर अनुकरण करता है। हालांकि, [[एनएक्स बिट]] का अनुकरण या आपूर्ति करने वाली प्रौद्योगिकियां आमतौर पर एक औसत दर्जे का ओवरहेड लगाती हैं, जबकि हार्डवेयर-आपूर्ति वाले एनएक्स बिट का उपयोग करने से कोई औसत दर्जे का ओवरहेड नहीं होता है।
{{more citations needed|date=April 2013}}


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


यदि कोई [[ऑपरेटिंग सिस्टम]] मेमोरी के कुछ या सभी लिखने योग्य क्षेत्रों को गैर-निष्पादन योग्य के रूप में चिह्नित कर सकता है, तो यह [[कॉल स्टैक]] और डायनेमिक मेमोरी आवंटन मेमोरी क्षेत्रों को निष्पादन योग्य होने से रोकने में सक्षम हो सकता है। यह कुछ [[ बफ़र अधिकता ]] [[शोषण (कंप्यूटर सुरक्षा)]] को सफल होने से रोकने में मदद करता है, विशेष रूप से वे जो कोड को इंजेक्ट और निष्पादित करते हैं, जैसे कि सैसर (कंप्यूटर वर्म) और [[ब्लास्टर (कंप्यूटर वर्म)]] वर्म्स। ये हमले मेमोरी के कुछ हिस्से पर निर्भर करते हैं, आमतौर पर स्टैक, लिखने योग्य और निष्पादन योग्य दोनों होने के कारण; यदि यह नहीं है, तो हमला विफल हो जाता है।
यदि कोई [[ऑपरेटिंग सिस्टम]] मेमोरी के कुछ या सभी लिखने योग्य क्षेत्रों को गैर-निष्पादन योग्य के रूप में चिह्नित कर सकता है, तो यह [[कॉल स्टैक]] और डायनेमिक मेमोरी आवंटन मेमोरी क्षेत्रों को निष्पादन योग्य होने से रोकने में सक्षम हो सकता है। यह कुछ [[ बफ़र अधिकता ]] [[शोषण (कंप्यूटर सुरक्षा)]] को सफल होने से रोकने में मदद करता है, विशेष रूप से वे जो कोड को इंजेक्ट और निष्पादित करते हैं, जैसे कि सैसर (कंप्यूटर वर्म) और [[ब्लास्टर (कंप्यूटर वर्म)]] वर्म्स। ये हमले मेमोरी के कुछ हिस्से पर निर्भर करते हैं, आमतौर पर स्टैक, लिखने योग्य और निष्पादन योग्य दोनों होने के कारण; यदि यह नहीं है, तो हमला विफल हो जाता है।
Line 23: Line 20:
=== एंड्रॉइड ===
=== एंड्रॉइड ===
एंड्रॉइड (ऑपरेटिंग सिस्टम) 2.3 और बाद में, इसका समर्थन करने वाले आर्किटेक्चर में गैर-निष्पादन योग्य स्टैक और हीप सहित डिफ़ॉल्ट रूप से गैर-निष्पादन योग्य पृष्ठ हैं।
एंड्रॉइड (ऑपरेटिंग सिस्टम) 2.3 और बाद में, इसका समर्थन करने वाले आर्किटेक्चर में गैर-निष्पादन योग्य स्टैक और हीप सहित डिफ़ॉल्ट रूप से गैर-निष्पादन योग्य पृष्ठ हैं।
<ref>"Memory Management Security Enhancements", [http://source.android.com/tech/security/#memory-management-security-enhancements Android Security Overview], retrieved 2012/07/29.</ref>
<ref>"Memory Management Security Enhancements", [http://source.android.com/tech/security/#memory-management-security-enhancements Android Security Overview], retrieved 2012/07/29.</ref>
<ref>{{cite web|title=Android कोड परिवर्तन डिफ़ॉल्ट रूप से NX को सक्षम करता है।|url=https://android.googlesource.com/platform/build/+/2915cc3e323a9bf86e1a20b201ceb4e9529bc5a2%5E%21/|website=Android Source Repository Change|access-date=2019-08-27}}</ref>
<ref>{{cite web|title=Android कोड परिवर्तन डिफ़ॉल्ट रूप से NX को सक्षम करता है।|url=https://android.googlesource.com/platform/build/+/2915cc3e323a9bf86e1a20b201ceb4e9529bc5a2%5E%21/|website=Android Source Repository Change|access-date=2019-08-27}}</ref>
<ref>{{cite web|title=एनएक्स के लिए एंड्रॉइड संगतता आवश्यकता|url=https://android-review.googlesource.com/c/platform/cts/+/21776|website=Android Code Review|access-date=2019-08-27}}</ref>
<ref>{{cite web|title=एनएक्स के लिए एंड्रॉइड संगतता आवश्यकता|url=https://android-review.googlesource.com/c/platform/cts/+/21776|website=Android Code Review|access-date=2019-08-27}}</ref>




Line 38: Line 39:
  | website = kernelnewbies.org
  | website = kernelnewbies.org
}}</ref>
}}</ref>
32-बिट x86 कर्नेल पर NX बिट की उपलब्धता, जो 32-बिट x86 CPU और 64-बिट IA-32-संगत CPU दोनों पर चल सकती है, महत्वपूर्ण है क्योंकि 32-बिट x86 कर्नेल सामान्य रूप से NX बिट की अपेक्षा नहीं करेगा। कि एक x86-64 या [[IA-64]] आपूर्ति करता है; एनएक्स एनबलर पैच आश्वासन देता है कि ये कर्नेल मौजूद होने पर एनएक्स बिट का उपयोग करने का प्रयास करेंगे।
32-बिट x86 कर्नेल पर NX बिट की उपलब्धता, जो 32-बिट x86 CPU और 64-बिट IA-32-संगत CPU दोनों पर चल सकती है, महत्वपूर्ण है क्योंकि 32-बिट x86 कर्नेल सामान्य रूप से NX बिट की अपेक्षा नहीं करेगा। कि एक x86-64 या [[IA-64]] आपूर्ति करता है; एनएक्स एनबलर पैच आश्वासन देता है कि ये कर्नेल मौजूद होने पर एनएक्स बिट का उपयोग करने का प्रयास करेंगे।


Line 91: Line 93:
=== [[नेटबीएसडी]] ===
=== [[नेटबीएसडी]] ===
NetBSD 2.0 और बाद में (9 दिसंबर, 2004) तक, इसका समर्थन करने वाले आर्किटेक्चर में गैर-निष्पादन योग्य स्टैक और हीप है।
NetBSD 2.0 और बाद में (9 दिसंबर, 2004) तक, इसका समर्थन करने वाले आर्किटेक्चर में गैर-निष्पादन योग्य स्टैक और हीप है।
<ref>NetBSD, [http://www.netbsd.org/Documentation/kernel/non-exec.html Non-executable stack and heap], retrieved 2011/07/14.</ref>
<ref>NetBSD, [http://www.netbsd.org/Documentation/kernel/non-exec.html Non-executable stack and heap], retrieved 2011/07/14.</ref>
आर्किटेक्चर जिनमें प्रति-पृष्ठ ग्रैन्युलैरिटी शामिल है: DEC Alpha, x86-64, PA-RISC, IA-32 (भौतिक पता एक्सटेंशन के साथ), PowerPC (ibm4xx), SuperH#SH-5, SPARC ([[Sun-4m]], Sun- 4डी), स्पार्क64.
 
आर्किटेक्चर जिनमें प्रति-पृष्ठ ग्रैन्युलैरिटी शामिल है: DEC Alpha, x86-64, PA-RISC, IA-32 (भौतिक पता एक्सटेंशन के साथ), PowerPC (ibm4xx), SuperH SH-5, SPARC ([[Sun-4m]], Sun- 4डी), स्पार्क64.


आर्किटेक्चर जो केवल क्षेत्र ग्रैन्युलैरिटी के साथ इनका समर्थन कर सकते हैं वे हैं: i386 (PAE के बिना), अन्य powerpc (जैसे macppc)।
आर्किटेक्चर जो केवल क्षेत्र ग्रैन्युलैरिटी के साथ इनका समर्थन कर सकते हैं वे हैं: i386 (PAE के बिना), अन्य powerpc (जैसे macppc)।
Line 124: Line 128:


Microsoft के सुरक्षित [[संरचित अपवाद हैंडलिंग]] (SafeSEH) के माध्यम से Windows सॉफ़्टवेयर DEP (NX बिट के उपयोग के बिना) को लागू करता है। ठीक से संकलित अनुप्रयोगों के लिए, SafeSEH जाँचता है कि, जब प्रोग्राम निष्पादन के दौरान एक अपवाद उठाया जाता है, तो अपवाद का हैंडलर वह होता है जिसे एप्लिकेशन द्वारा मूल रूप से संकलित किया गया था। इस सुरक्षा का प्रभाव यह है कि एक हमलावर अपने स्वयं के अपवाद हैंडलर को जोड़ने में सक्षम नहीं होता है जिसे उसने अनियंत्रित प्रोग्राम इनपुट के माध्यम से डेटा पेज में संग्रहीत किया है।<ref name="KB875352" /><ref>{{cite web|last1=Johnson |first1=Peter |title=Yasm User Manual, win32: Safe Structured Exception Handling |url=http://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.html |website=Tortall Networks: Open Source and Free Software |access-date=27 September 2015 |url-status=dead |archive-url=https://web.archive.org/web/20150102223308/http://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.html |archive-date=January 2, 2015 }}</ref>
Microsoft के सुरक्षित [[संरचित अपवाद हैंडलिंग]] (SafeSEH) के माध्यम से Windows सॉफ़्टवेयर DEP (NX बिट के उपयोग के बिना) को लागू करता है। ठीक से संकलित अनुप्रयोगों के लिए, SafeSEH जाँचता है कि, जब प्रोग्राम निष्पादन के दौरान एक अपवाद उठाया जाता है, तो अपवाद का हैंडलर वह होता है जिसे एप्लिकेशन द्वारा मूल रूप से संकलित किया गया था। इस सुरक्षा का प्रभाव यह है कि एक हमलावर अपने स्वयं के अपवाद हैंडलर को जोड़ने में सक्षम नहीं होता है जिसे उसने अनियंत्रित प्रोग्राम इनपुट के माध्यम से डेटा पेज में संग्रहीत किया है।<ref name="KB875352" /><ref>{{cite web|last1=Johnson |first1=Peter |title=Yasm User Manual, win32: Safe Structured Exception Handling |url=http://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.html |website=Tortall Networks: Open Source and Free Software |access-date=27 September 2015 |url-status=dead |archive-url=https://web.archive.org/web/20150102223308/http://www.tortall.net/projects/yasm/manual/html/objfmt-win32-safeseh.html |archive-date=January 2, 2015 }}</ref>
जब एनएक्स समर्थित होता है, तो यह डिफ़ॉल्ट रूप से सक्षम होता है। विंडोज़ प्रोग्राम को यह नियंत्रित करने की अनुमति देता है कि कौन से पृष्ठ अपने [[एपीआई]] के साथ-साथ [[पोर्टेबल निष्पादन योग्य]] में सेक्शन हेडर के माध्यम से निष्पादन को अस्वीकार करते हैं। एपीआई में, [[Win32]] एपीआई कॉल के माध्यम से एनएक्स बिट तक रनटाइम पहुंच का खुलासा किया गया है {{mono|VirtualAlloc[Ex]}} और {{mono|VirtualProtect[Ex]}}. प्रत्येक पृष्ठ को निष्पादन योग्य या गैर-निष्पादन योग्य के रूप में व्यक्तिगत रूप से फ़्लैग किया जा सकता है। पिछले x86 हार्डवेयर समर्थन की कमी के बावजूद, शुरुआत से ही निष्पादन योग्य और गैर-निष्पादन योग्य दोनों पृष्ठ सेटिंग्स प्रदान की गई हैं। प्री-एनएक्स सीपीयू पर, 'निष्पादन योग्य' विशेषता की उपस्थिति का कोई प्रभाव नहीं पड़ता है। इसे प्रलेखित किया गया था जैसे कि यह कार्य करता था, और, परिणामस्वरूप, अधिकांश प्रोग्रामर ने इसे ठीक से उपयोग किया। पीई फ़ाइल स्वरूप में, प्रत्येक अनुभाग अपनी निष्पादन क्षमता निर्दिष्ट कर सकता है। निष्पादन ध्वज प्रारूप की शुरुआत के बाद से अस्तित्व में है और मानक [[लिंकर (कंप्यूटिंग)]] ने हमेशा इस ध्वज का सही ढंग से उपयोग किया है, एनएक्स बिट से बहुत पहले भी। इस वजह से, विंडोज़ पुराने कार्यक्रमों पर एनएक्स बिट लागू करने में सक्षम है। यह मानते हुए कि प्रोग्रामर ने सर्वोत्तम प्रथाओं का अनुपालन किया है, अनुप्रयोगों को अब ठीक से काम करना चाहिए क्योंकि NX वास्तव में लागू है। केवल कुछ ही मामलों में समस्याएँ रही हैं; Microsoft के अपने .NET रनटाइम में NX बिट के साथ समस्या थी और इसे अपडेट किया गया था।
जब एनएक्स समर्थित होता है, तो यह डिफ़ॉल्ट रूप से सक्षम होता है। विंडोज़ प्रोग्राम को यह नियंत्रित करने की अनुमति देता है कि कौन से पृष्ठ अपने [[एपीआई]] के साथ-साथ [[पोर्टेबल निष्पादन योग्य]] में सेक्शन हेडर के माध्यम से निष्पादन को अस्वीकार करते हैं। एपीआई में, [[Win32]] एपीआई कॉल के माध्यम से एनएक्स बिट तक रनटाइम पहुंच का खुलासा किया गया है {{mono|VirtualAlloc[Ex]}} और {{mono|VirtualProtect[Ex]}}. प्रत्येक पृष्ठ को निष्पादन योग्य या गैर-निष्पादन योग्य के रूप में व्यक्तिगत रूप से फ़्लैग किया जा सकता है। पिछले x86 हार्डवेयर समर्थन की कमी के बावजूद, शुरुआत से ही निष्पादन योग्य और गैर-निष्पादन योग्य दोनों पृष्ठ सेटिंग्स प्रदान की गई हैं। प्री-एनएक्स सीपीयू पर, 'निष्पादन योग्य' विशेषता की उपस्थिति का कोई प्रभाव नहीं पड़ता है। इसे प्रलेखित किया गया था जैसे कि यह कार्य करता था, और, परिणामस्वरूप, अधिकांश प्रोग्रामर ने इसे ठीक से उपयोग किया। पीई फ़ाइल स्वरूप में, प्रत्येक अनुभाग अपनी निष्पादन क्षमता निर्दिष्ट कर सकता है। निष्पादन ध्वज प्रारूप की शुरुआत के बाद से अस्तित्व में है और मानक [[लिंकर (कंप्यूटिंग)]] ने हमेशा इस ध्वज का सही ढंग से उपयोग किया है, एनएक्स बिट से बहुत पहले भी। इस वजह से, विंडोज़ पुराने कार्यक्रमों पर एनएक्स बिट लागू करने में सक्षम है। यह मानते हुए कि प्रोग्रामर ने सर्वोत्तम प्रथाओं का अनुपालन किया है, अनुप्रयोगों को अब ठीक से काम करना चाहिए क्योंकि NX वास्तव में लागू है। केवल कुछ ही मामलों में समस्याएँ रही हैं; Microsoft के अपने .NET रनटाइम में NX बिट के साथ समस्या थी और इसे अपडेट किया गया था।


Line 133: Line 138:


=== एक्सबॉक्स ===
=== एक्सबॉक्स ===
Microsoft के Xbox (कंसोल) में, हालाँकि CPU में NX बिट नहीं है, Xbox डेवलपमेंट किट के नए संस्करण कर्नेल के .data सेक्शन की शुरुआत में कोड सेगमेंट की सीमा निर्धारित करते हैं (सामान्य परिस्थितियों में इस बिंदु के बाद कोई कोड नहीं होना चाहिए) . संस्करण 51xx से शुरू हो रहा है<!--someone please fill this in-->, यह परिवर्तन नए Xbox के कर्नेल में भी लागू किया गया था। इसने उन तकनीकों को तोड़ दिया जो पुराने कारनामे एक [[टर्मिनेट-एंड-स्टे-रेजिडेंट प्रोग्राम]] बनते थे। हालाँकि, इस नए कर्नेल संस्करण का समर्थन करते हुए नए कारनामे जल्दी से जारी किए गए क्योंकि Xbox कर्नेल में मूलभूत भेद्यता अप्रभावित थी।
Microsoft के Xbox (कंसोल) में, हालाँकि CPU में NX बिट नहीं है, Xbox डेवलपमेंट किट के नए संस्करण कर्नेल के .data सेक्शन की शुरुआत में कोड सेगमेंट की सीमा निर्धारित करते हैं (सामान्य परिस्थितियों में इस बिंदु के बाद कोई कोड नहीं होना चाहिए) . संस्करण 51xx से शुरू हो रहा है, यह परिवर्तन नए Xbox के कर्नेल में भी लागू किया गया था। इसने उन तकनीकों को तोड़ दिया जो पुराने कारनामे एक [[टर्मिनेट-एंड-स्टे-रेजिडेंट प्रोग्राम]] बनते थे। हालाँकि, इस नए कर्नेल संस्करण का समर्थन करते हुए नए कारनामे जल्दी से जारी किए गए क्योंकि Xbox कर्नेल में मूलभूत भेद्यता अप्रभावित थी।


== सीमाएं ==
== सीमाएं ==
जहां रनटाइम पर कोड लिखा और निष्पादित किया जाता है - एक JIT कंपाइलर एक प्रमुख उदाहरण है [[जेआईटी कंपाइलर]] का उपयोग संभावित रूप से शोषण कोड (जैसे JIT स्प्रे का उपयोग करके) का उत्पादन करने के लिए किया जा सकता है जिसे निष्पादन के लिए फ़्लैग किया गया है और इसलिए फंसाया नहीं जाएगा।<ref>{{cite web|url=http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Paper.pdf|title=Interpreter Exploitation: Pointer Inference And JIT Spraying|author=Dion Blazakis}}</ref><ref name="dsecrg">{{cite web|url=http://dsecrg.com/files/pub/pdf/Writing%20JIT-Spray%20Shellcode%20for%20fun%20and%20profit.pdf|title=मनोरंजन और लाभ के लिए JIT-Spray Shellcode लिखना|author=Alexey Sintsov|date=March 5, 2010|archive-url=https://web.archive.org/web/20160304110012/http://dsecrg.com/files/pub/pdf/Writing%20JIT-Spray%20Shellcode%20for%20fun%20and%20profit.pdf|archive-date=2016-03-04}}</ref>
जहां रनटाइम पर कोड लिखा और निष्पादित किया जाता है - एक JIT कंपाइलर एक प्रमुख उदाहरण है [[जेआईटी कंपाइलर]] का उपयोग संभावित रूप से शोषण कोड (जैसे JIT स्प्रे का उपयोग करके) का उत्पादन करने के लिए किया जा सकता है जिसे निष्पादन के लिए फ़्लैग किया गया है और इसलिए फंसाया नहीं जाएगा।<ref>{{cite web|url=http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Paper.pdf|title=Interpreter Exploitation: Pointer Inference And JIT Spraying|author=Dion Blazakis}}</ref><ref name="dsecrg">{{cite web|url=http://dsecrg.com/files/pub/pdf/Writing%20JIT-Spray%20Shellcode%20for%20fun%20and%20profit.pdf|title=मनोरंजन और लाभ के लिए JIT-Spray Shellcode लिखना|author=Alexey Sintsov|date=March 5, 2010|archive-url=https://web.archive.org/web/20160304110012/http://dsecrg.com/files/pub/pdf/Writing%20JIT-Spray%20Shellcode%20for%20fun%20and%20profit.pdf|archive-date=2016-03-04}}</ref>
[[ वापसी-उन्मुख प्रोग्रामिंग ]] एक हमलावर को मनमाना कोड निष्पादित करने की अनुमति दे सकती है, भले ही निष्पादन योग्य स्थान सुरक्षा लागू हो।
 
[[ वापसी-उन्मुख प्रोग्रामिंग |वापसी-उन्मुख प्रोग्रामिंग]] एक हमलावर को मनमाना कोड निष्पादित करने की अनुमति दे सकती है, भले ही निष्पादन योग्य स्थान सुरक्षा लागू हो।


== यह भी देखें ==
== यह भी देखें ==

Revision as of 21:43, 28 April 2023

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

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

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

ओएस कार्यान्वयन

कई ऑपरेटिंग सिस्टम निष्पादन योग्य अंतरिक्ष सुरक्षा नीति को लागू करते हैं या उपलब्ध कराते हैं। यहां वर्णानुक्रम में ऐसी प्रणालियों की एक सूची दी गई है, जिनमें से प्रत्येक में नई से पुरानी तकनीकों का क्रम दिया गया है।

कुछ तकनीकों के लिए, एक सारांश है जो प्रत्येक तकनीक द्वारा समर्थित प्रमुख विशेषताओं को बताता है। सारांश नीचे के रूप में संरचित है।

  • हार्डवेयर समर्थित प्रोसेसर: (सीपीयू आर्किटेक्चर की अल्पविराम से अलग की गई सूची)
  • एमुलेशन: (नहीं) या (आर्किटेक्चर इंडिपेंडेंट) या (सीपीयू आर्किटेक्चर की कोमा से अलग की गई सूची)
  • अन्य समर्थित: (कोई नहीं) या (सीपीयू आर्किटेक्चर की अल्पविराम से अलग की गई सूची)
  • मानक वितरण: (नहीं) या (हां) या (अल्पविराम से अलग की गई वितरणों की सूची या संस्करण जो प्रौद्योगिकी का समर्थन करते हैं)
  • रिलीज की तारीख: (पहली रिलीज की तारीख)

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

एंड्रॉइड

एंड्रॉइड (ऑपरेटिंग सिस्टम) 2.3 और बाद में, इसका समर्थन करने वाले आर्किटेक्चर में गैर-निष्पादन योग्य स्टैक और हीप सहित डिफ़ॉल्ट रूप से गैर-निष्पादन योग्य पृष्ठ हैं।

[1]

[2]

[3]


फ्रीबीएसडी

NX बिट के लिए प्रारंभिक समर्थन, x86-64 और IA-32 प्रोसेसर पर जो इसका समर्थन करते हैं, पहली बार 8 जून, 2004 को FreeBSD -CURRENT में दिखाई दिए। यह 5.3 रिलीज के बाद से FreeBSD रिलीज़ में है।

लिनक्स

लिनक्स कर्नेल x86-64 और IA-32 प्रोसेसर पर NX बिट का समर्थन करता है जो इसका समर्थन करता है, जैसे AMD, Intel, Transmeta और VIA द्वारा बनाए गए आधुनिक 64-बिट प्रोसेसर। x86-64 CPU पर 64-बिट मोड में इस सुविधा के लिए समर्थन 2004 में Andi Kleen द्वारा जोड़ा गया था, और बाद में उसी वर्ष, Ingo Molnár ने 64-बिट CPU पर 32-बिट मोड में इसके लिए समर्थन जोड़ा। अगस्त 2004 में कर्नेल संस्करण 2.6.8 के जारी होने के बाद से ये विशेषताएं लिनक्स कर्नेल मेनलाइन का हिस्सा रही हैं।[4]

32-बिट x86 कर्नेल पर NX बिट की उपलब्धता, जो 32-बिट x86 CPU और 64-बिट IA-32-संगत CPU दोनों पर चल सकती है, महत्वपूर्ण है क्योंकि 32-बिट x86 कर्नेल सामान्य रूप से NX बिट की अपेक्षा नहीं करेगा। कि एक x86-64 या IA-64 आपूर्ति करता है; एनएक्स एनबलर पैच आश्वासन देता है कि ये कर्नेल मौजूद होने पर एनएक्स बिट का उपयोग करने का प्रयास करेंगे।

कुछ डेस्कटॉप लिनक्स वितरण, जैसे फेडोरा लिनक्स, उबंटू (ऑपरेटिंग सिस्टम) और ओपनएसयूएसई, अपने डिफ़ॉल्ट कर्नेल में डिफ़ॉल्ट रूप से HighHMEM64 विकल्प को सक्षम नहीं करते हैं, जो कि 32-बिट मोड में NX बिट तक पहुंच प्राप्त करने के लिए आवश्यक है, क्योंकि भौतिक एनएक्स बिट का उपयोग करने के लिए भौतिक पता विस्तार मोड प्री-पेंटियम प्रो (पेंटियम एमएमएक्स समेत) और सेलेरॉन एम और पेंटियम एम प्रोसेसर पर एनएक्स समर्थन के बिना बूट विफलता का कारण बनता है। अन्य प्रोसेसर जो पीएई का समर्थन नहीं करते हैं वे हैं AMD K6 और पहले के संस्करण, Transmeta Crusoe, VIA C3 और पहले के संस्करण, और Geode (प्रोसेसर) GX और LX। 4.0 से पुराने VMware वर्कस्टेशन वर्जन, 4.0 से पुराने समानांतर कार्य केंद्र वर्जन और माइक्रोसॉफ्ट वर्चुअल पीसी और माइक्रोसॉफ्ट वर्चुअल सर्वर अतिथि पर पीएई का समर्थन नहीं करते हैं। फेडोरा कोर 6 और उबंटू 9.10 और बाद में कर्नेल-पीएई पैकेज प्रदान करता है जो पीएई और एनएक्स का समर्थन करता है।

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

कई रिलीज के लिए इस कार्यक्षमता का समर्थन करने वाले अन्य गैर-x86 प्रोसेसर के लिए गैर-निष्पादित कार्यक्षमता भी मौजूद है।

एक्ज़ेक शील्ड

Red Hat कर्नेल डेवलपर Ingo Molnár ने 32-बिट x86 CPU पर NX कार्यक्षमता का अनुमान लगाने और उपयोग करने के लिए Exec Shield नाम का एक Linux कर्नेल पैच जारी किया। Exec Shield पैच 2 मई, 2003 को लिनक्स कर्नेल मेलिंग सूची में जारी किया गया था, लेकिन बेस कर्नेल के साथ विलय के लिए इसे अस्वीकार कर दिया गया था क्योंकि इसमें अनुकरण के जटिल भागों को संभालने के लिए कोर कोड में कुछ दखल देने वाले परिवर्तन शामिल थे। Exec Shield का पुराना CPU समर्थन ऊपरी कोड खंड सीमा को ट्रैक करके NX अनुकरण का अनुमान लगाता है। यह संदर्भ स्विच के दौरान ओवरहेड के केवल कुछ चक्र लगाता है, जो सभी उद्देश्यों और उद्देश्यों के लिए अथाह है। एनएक्स बिट के बिना लीगेसी सीपीयू के लिए, एक्सेक शील्ड कोड सेगमेंट सीमा से नीचे के पेजों की सुरक्षा करने में विफल रहता है; उच्च मेमोरी को चिह्नित करने के लिए एक एमप्रोटेक्ट () कॉल, जैसे स्टैक, निष्पादन योग्य उस सीमा से नीचे की सभी मेमोरी को निष्पादन योग्य भी चिह्नित करेगा। इस प्रकार, इन स्थितियों में, Exec Shield की योजनाएँ विफल हो जाती हैं। यह एक्ज़ेक शील्ड के लो ओवरहेड की लागत है। Exec Shield दो निष्पादन योग्य और लिंक करने योग्य प्रारूप हेडर मार्किंग की जांच करता है, जो यह निर्धारित करता है कि स्टैक या हीप को एक्जीक्यूटेबल होने की जरूरत है या नहीं। इन्हें क्रमशः PT_GNU_STACK और PT_GNU_HEAP कहा जाता है। Exec Shield इन नियंत्रणों को बाइनरी एक्जीक्यूटेबल और लाइब्रेरी दोनों के लिए सेट करने की अनुमति देता है; यदि एक निष्पादन योग्य किसी पुस्तकालय को किसी दिए गए प्रतिबंध को शिथिल करने की आवश्यकता होती है, तो निष्पादन योग्य उस अंकन को प्राप्त करेगा और उस प्रतिबंध को शिथिल कर देगा।

  • हार्डवेयर समर्थित प्रोसेसर: वह सब जो Linux NX को सपोर्ट करता है
  • अनुकरण: IA-32 (x86) और संगत पर कोड खंड सीमा का उपयोग करके NX सन्निकटन
  • अन्य समर्थित: कोई नहीं
  • मानक वितरण: फेडोरा कोर और रेड हैट एंटरप्राइज लिनक्स
  • रिलीज की तारीख: 2 मई, 2003

पैक्स

"PaX" redirects here. For other uses, see Pax (disambiguation).

पैक्स एनएक्स तकनीक एनएक्स कार्यक्षमता का अनुकरण कर सकती है, या हार्डवेयर एनएक्स बिट का उपयोग कर सकती है। PaX x86 CPU पर काम करता है जिसमें NX बिट नहीं है, जैसे कि 32-बिट x86। Linux कर्नेल (ऑपरेटिंग सिस्टम) अभी भी PaX (मई, 2007 तक) के साथ शिप नहीं करता है; पैच को मैन्युअल रूप से मर्ज किया जाना चाहिए।

PaX NX बिट एमुलेशन के दो तरीके प्रदान करता है, जिन्हें SEGMEXEC और PAGEEXEC कहा जाता है। SEGMEXEC विधि एक औसत दर्जे का लेकिन कम ओवरहेड लगाती है, आमतौर पर 1% से कम, जो निष्पादन और डेटा एक्सेस के बीच अलगाव के लिए उपयोग की जाने वाली वर्चुअल मेमोरी मिररिंग के कारण होने वाला एक निरंतर स्केलर है।[5] SEGMEXEC में कार्य के वर्चुअल एड्रेस स्पेस को आधा करने का भी प्रभाव होता है, जिससे कार्य को सामान्य रूप से कम मेमोरी तक पहुंचने की अनुमति मिलती है। यह तब तक कोई समस्या नहीं है जब तक कि कार्य को सामान्य पता स्थान के आधे से अधिक तक पहुंच की आवश्यकता न हो, जो दुर्लभ है। SEGMEXEC प्रोग्राम को अधिक सिस्टम मेमोरी (अर्थात RAM) का उपयोग करने का कारण नहीं बनाता है, यह केवल प्रतिबंधित करता है कि वे कितना एक्सेस कर सकते हैं। 32-बिट CPU पर, यह 3GB के बजाय 1.5GB हो जाता है।

PaX स्पीडअप के रूप में PAGEEXEC में Exec Shield के सन्निकटन के समान एक विधि प्रदान करता है; हालाँकि, जब उच्च मेमोरी को निष्पादन योग्य के रूप में चिह्नित किया जाता है, तो यह विधि अपनी सुरक्षा खो देती है। इन मामलों में, PaX CS सीमा से नीचे के पृष्ठों की सुरक्षा के लिए PAGEEXEC द्वारा उपयोग की जाने वाली पुरानी, ​​चर-ओवरहेड विधि पर वापस आ जाता है, जो कुछ मेमोरी एक्सेस पैटर्न में काफी उच्च-ओवरहेड ऑपरेशन बन सकता है। जब हार्डवेयर NX बिट की आपूर्ति करने वाले CPU पर PAGEEXEC विधि का उपयोग किया जाता है, तो हार्डवेयर NX बिट का उपयोग किया जाता है, इस प्रकार कोई महत्वपूर्ण ओवरहेड नहीं होता है।

PaX मेमोरी को उन तरीकों से चिह्नित करने से प्रोग्राम को रोकने के लिए mprotect() प्रतिबंधों की आपूर्ति करता है जो एक संभावित शोषण_(कंप्यूटर_सुरक्षा) के लिए उपयोगी मेमोरी उत्पन्न करते हैं। इस नीति के कारण कुछ एप्लिकेशन कार्य करना बंद कर देते हैं, लेकिन इसे प्रभावित कार्यक्रमों के लिए अक्षम किया जा सकता है।

PaX प्रत्येक बाइनरी निष्पादन योग्य के लिए प्रौद्योगिकी के निम्नलिखित कार्यों पर व्यक्तिगत नियंत्रण की अनुमति देता है:

  • पेजईएक्सईसी
  • सेगमेक्सिक
  • एमप्रोटेक्ट () प्रतिबंध
  • ट्रैम्पोलिन (कंप्यूटिंग) अनुकरण
  • यादृच्छिक निष्पादन योग्य आधार
  • यादृच्छिक एमएमएपी () आधार

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

मैकोज़

Intel के लिए macOS Apple द्वारा समर्थित सभी CPU पर NX बिट का समर्थन करता है (Mac OS X 10.4.4 से - पहला Intel रिलीज़ - बाद में)। Mac OS X 10.4 केवल NX स्टैक सुरक्षा का समर्थन करता है। Mac OS X 10.5 में, सभी 64-बिट एक्जीक्यूटेबल में NX स्टैक और हीप है; डब्ल्यू ^ एक्स सुरक्षा। इसमें x86-64 (कोर 2 या बाद का संस्करण) और PowerPC 970 Mac पर 64-बिट PowerPC शामिल है।

नेटबीएसडी

NetBSD 2.0 और बाद में (9 दिसंबर, 2004) तक, इसका समर्थन करने वाले आर्किटेक्चर में गैर-निष्पादन योग्य स्टैक और हीप है।

[6]

आर्किटेक्चर जिनमें प्रति-पृष्ठ ग्रैन्युलैरिटी शामिल है: DEC Alpha, x86-64, PA-RISC, IA-32 (भौतिक पता एक्सटेंशन के साथ), PowerPC (ibm4xx), SuperH SH-5, SPARC (Sun-4m, Sun- 4डी), स्पार्क64.

आर्किटेक्चर जो केवल क्षेत्र ग्रैन्युलैरिटी के साथ इनका समर्थन कर सकते हैं वे हैं: i386 (PAE के बिना), अन्य powerpc (जैसे macppc)।

अन्य आर्किटेक्चर गैर-निष्पादन योग्य स्टैक या हीप से लाभान्वित नहीं होते हैं; NetBSD उन आर्किटेक्चर पर इन सुविधाओं की पेशकश करने के लिए डिफ़ॉल्ट रूप से किसी सॉफ़्टवेयर एमुलेशन का उपयोग नहीं करता है।

ओपनबीएसडी

Main article: W^X

OpenBSD ऑपरेटिंग सिस्टम में एक तकनीक, जिसे W^X के रूप में जाना जाता है, लिखने योग्य पृष्ठों को डिफ़ॉल्ट रूप से उन प्रोसेसर पर गैर-निष्पादन योग्य के रूप में चिह्नित करती है जो इसका समर्थन करते हैं। 32-बिट x86 प्रोसेसर पर, कोड सेगमेंट को निष्पादन योग्य स्थान सुरक्षा के कुछ स्तर प्रदान करने के लिए पता स्थान का केवल एक हिस्सा शामिल करने के लिए सेट किया गया है।

OpenBSD 3.3 को 1 मई, 2003 को भेज दिया गया था, और W^X को शामिल करने वाला पहला था।

  • हार्डवेयर समर्थित प्रोसेसर: DEC Alpha, AMD64, PA-RISC, SPARC
  • अनुकरण: IA-32 (x86)
  • अन्य समर्थित: कोई नहीं
  • मानक वितरण: हाँ
  • रिलीज की तारीख: 1 मई, 2003

सोलारिस

Solaris (ऑपरेटिंग सिस्टम) ने Solaris 2.6 (1997) के बाद से SPARC प्रोसेसरों पर स्टैक निष्पादन को विश्व स्तर पर अक्षम करने का समर्थन किया है; सोलारिस 9 (2002) में, प्रति-निष्पादन योग्य आधार पर स्टैक निष्पादन को अक्षम करने के लिए समर्थन जोड़ा गया था।

विंडोज

Windows XP सर्विस पैक 2 (2004) और Windows Server 2003 सर्विस पैक 1 (2005) से शुरू होकर, NX सुविधाओं को पहली बार x86 आर्किटेक्चर पर लागू किया गया था। विंडोज़ पर निष्पादन योग्य स्थान सुरक्षा को डेटा निष्पादन रोकथाम (डीईपी) कहा जाता है।

विन्डोज़ एक्सपी या सर्वर 2003 एनएक्स के तहत विशेष रूप से डिफ़ॉल्ट रूप से महत्वपूर्ण विंडोज़ सेवा पर सुरक्षा का उपयोग किया गया था। यदि x86 प्रोसेसर हार्डवेयर में इस सुविधा का समर्थन करता है, तो डिफ़ॉल्ट रूप से Windows XP/Server 2003 में NX सुविधाएँ स्वचालित रूप से चालू हो जाती हैं। यदि सुविधा x86 प्रोसेसर द्वारा समर्थित नहीं थी, तो कोई सुरक्षा नहीं दी गई थी।

डीईपी के शुरुआती कार्यान्वयन ने कोई पता स्थान लेआउट रेंडमाइजेशन (एएसएलआर) प्रदान नहीं किया, जिसने संभावित रिटर्न-टू-लिबसी हमलों की अनुमति दी, जो संभवतः एक हमले के दौरान डीईपी को अक्षम करने के लिए इस्तेमाल किया जा सकता था।[7] PaX प्रलेखन विस्तार से बताता है कि ASLR क्यों आवश्यक है;[8] एक प्रूफ-ऑफ-कॉन्सेप्ट तैयार किया गया था जिसमें एक ऐसी विधि का विवरण दिया गया था जिसके द्वारा एएसएलआर की अनुपस्थिति में डीईपी को दरकिनार किया जा सकता था।[9] एक सफल हमला विकसित करना संभव हो सकता है यदि तैयार डेटा जैसे दूषित चित्र या MP3 का पता हमलावर द्वारा जाना जा सकता है।

Microsoft ने Windows Vista और Windows Server 2008 में ASLR कार्यक्षमता जोड़ी। इस प्लेटफ़ॉर्म पर, DEP को 32-बिट विंडोज़ में भौतिक पता एक्सटेंशन कर्नेल (ऑपरेटिंग सिस्टम) के स्वचालित उपयोग और 64-बिट कर्नेल पर मूल समर्थन के माध्यम से कार्यान्वित किया जाता है। विंडोज़ विस्टा डीईपी स्मृति के कुछ हिस्सों को केवल डेटा रखने के इरादे से चिह्नित करके काम करता है, जिसे एनएक्स या एक्सडी बिट सक्षम प्रोसेसर तब गैर-निष्पादन योग्य समझता है।[10] विंडोज़ में, संस्करण विस्टा से, किसी विशेष प्रक्रिया के लिए डीईपी सक्षम या अक्षम है या नहीं, कार्य प्रबंधक (विंडोज़) में प्रक्रिया/विवरण टैब पर देखा जा सकता है।

Microsoft के सुरक्षित संरचित अपवाद हैंडलिंग (SafeSEH) के माध्यम से Windows सॉफ़्टवेयर DEP (NX बिट के उपयोग के बिना) को लागू करता है। ठीक से संकलित अनुप्रयोगों के लिए, SafeSEH जाँचता है कि, जब प्रोग्राम निष्पादन के दौरान एक अपवाद उठाया जाता है, तो अपवाद का हैंडलर वह होता है जिसे एप्लिकेशन द्वारा मूल रूप से संकलित किया गया था। इस सुरक्षा का प्रभाव यह है कि एक हमलावर अपने स्वयं के अपवाद हैंडलर को जोड़ने में सक्षम नहीं होता है जिसे उसने अनियंत्रित प्रोग्राम इनपुट के माध्यम से डेटा पेज में संग्रहीत किया है।[10][11]

जब एनएक्स समर्थित होता है, तो यह डिफ़ॉल्ट रूप से सक्षम होता है। विंडोज़ प्रोग्राम को यह नियंत्रित करने की अनुमति देता है कि कौन से पृष्ठ अपने एपीआई के साथ-साथ पोर्टेबल निष्पादन योग्य में सेक्शन हेडर के माध्यम से निष्पादन को अस्वीकार करते हैं। एपीआई में, Win32 एपीआई कॉल के माध्यम से एनएक्स बिट तक रनटाइम पहुंच का खुलासा किया गया है VirtualAlloc[Ex] और VirtualProtect[Ex]. प्रत्येक पृष्ठ को निष्पादन योग्य या गैर-निष्पादन योग्य के रूप में व्यक्तिगत रूप से फ़्लैग किया जा सकता है। पिछले x86 हार्डवेयर समर्थन की कमी के बावजूद, शुरुआत से ही निष्पादन योग्य और गैर-निष्पादन योग्य दोनों पृष्ठ सेटिंग्स प्रदान की गई हैं। प्री-एनएक्स सीपीयू पर, 'निष्पादन योग्य' विशेषता की उपस्थिति का कोई प्रभाव नहीं पड़ता है। इसे प्रलेखित किया गया था जैसे कि यह कार्य करता था, और, परिणामस्वरूप, अधिकांश प्रोग्रामर ने इसे ठीक से उपयोग किया। पीई फ़ाइल स्वरूप में, प्रत्येक अनुभाग अपनी निष्पादन क्षमता निर्दिष्ट कर सकता है। निष्पादन ध्वज प्रारूप की शुरुआत के बाद से अस्तित्व में है और मानक लिंकर (कंप्यूटिंग) ने हमेशा इस ध्वज का सही ढंग से उपयोग किया है, एनएक्स बिट से बहुत पहले भी। इस वजह से, विंडोज़ पुराने कार्यक्रमों पर एनएक्स बिट लागू करने में सक्षम है। यह मानते हुए कि प्रोग्रामर ने सर्वोत्तम प्रथाओं का अनुपालन किया है, अनुप्रयोगों को अब ठीक से काम करना चाहिए क्योंकि NX वास्तव में लागू है। केवल कुछ ही मामलों में समस्याएँ रही हैं; Microsoft के अपने .NET रनटाइम में NX बिट के साथ समस्या थी और इसे अपडेट किया गया था।

  • हार्डवेयर समर्थित प्रोसेसर: x86-64 (AMD64 और Intel 64), IA-64, Transmeta Efficeon, Pentium M (बाद के संशोधन), Sempron (बाद के संशोधन)
  • अनुकरण: हाँ
  • अन्य समर्थित: कोई नहीं
  • मानक वितरण: Windows XP के बाद
  • रिलीज की तारीख: 6 अगस्त 2004

एक्सबॉक्स

Microsoft के Xbox (कंसोल) में, हालाँकि CPU में NX बिट नहीं है, Xbox डेवलपमेंट किट के नए संस्करण कर्नेल के .data सेक्शन की शुरुआत में कोड सेगमेंट की सीमा निर्धारित करते हैं (सामान्य परिस्थितियों में इस बिंदु के बाद कोई कोड नहीं होना चाहिए) . संस्करण 51xx से शुरू हो रहा है, यह परिवर्तन नए Xbox के कर्नेल में भी लागू किया गया था। इसने उन तकनीकों को तोड़ दिया जो पुराने कारनामे एक टर्मिनेट-एंड-स्टे-रेजिडेंट प्रोग्राम बनते थे। हालाँकि, इस नए कर्नेल संस्करण का समर्थन करते हुए नए कारनामे जल्दी से जारी किए गए क्योंकि Xbox कर्नेल में मूलभूत भेद्यता अप्रभावित थी।

सीमाएं

जहां रनटाइम पर कोड लिखा और निष्पादित किया जाता है - एक JIT कंपाइलर एक प्रमुख उदाहरण है जेआईटी कंपाइलर का उपयोग संभावित रूप से शोषण कोड (जैसे JIT स्प्रे का उपयोग करके) का उत्पादन करने के लिए किया जा सकता है जिसे निष्पादन के लिए फ़्लैग किया गया है और इसलिए फंसाया नहीं जाएगा।[12][13]

वापसी-उन्मुख प्रोग्रामिंग एक हमलावर को मनमाना कोड निष्पादित करने की अनुमति दे सकती है, भले ही निष्पादन योग्य स्थान सुरक्षा लागू हो।

यह भी देखें

संदर्भ

  1. ↑ "Memory Management Security Enhancements", Android Security Overview, retrieved 2012/07/29.
  2. ↑ "Android कोड परिवर्तन डिफ़ॉल्ट रूप से NX को सक्षम करता है।". Android Source Repository Change. Retrieved 2019-08-27.
  3. ↑ "एनएक्स के लिए एंड्रॉइड संगतता आवश्यकता". Android Code Review. Retrieved 2019-08-27.
  4. ↑ "Linux kernel 2.6.8". kernelnewbies.org. 2004-08-14. Retrieved 2015-08-01.
  5. ↑ "PaX SEGMEXEC documentation" (TXT). pax.grsecurity.net. September 10, 2004. Retrieved January 25, 2015.
  6. ↑ NetBSD, Non-executable stack and heap, retrieved 2011/07/14.
  7. ↑ "Blog on Cyberterror".
  8. ↑ "एड्रेस स्पेस लेआउट रैंडमाइजेशन". PaX project.
  9. ↑ "Uninformed - vol 2 article 4". Archived from the original on 2016-03-12. Retrieved 2010-03-19.
  10. ↑ 10.0 10.1 "A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003". Microsoft. 2006-09-26. Archived from the original on 2014-09-11. Retrieved 2008-07-11.
  11. ↑ Johnson, Peter. "Yasm User Manual, win32: Safe Structured Exception Handling". Tortall Networks: Open Source and Free Software. Archived from the original on January 2, 2015. Retrieved 27 September 2015.
  12. ↑ Dion Blazakis. "Interpreter Exploitation: Pointer Inference And JIT Spraying" (PDF).
  13. ↑ Alexey Sintsov (March 5, 2010). "मनोरंजन और लाभ के लिए JIT-Spray Shellcode लिखना" (PDF). Archived from the original (PDF) on 2016-03-04.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=निष्पादन_योग्य_स्पेस_सुरक्षा&oldid=160056’