वापसी-उन्मुख प्रोग्रामिंग

From Vigyanwiki
Revision as of 23:13, 17 February 2023 by alpha>Indicwiki (Created page with "{{use dmy dates|date=May 2022|cs1-dates=y}} रिटर्न-ओरिएंटेड प्रोग्रामिंग (आरओपी) एक कंप्यूट...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

रिटर्न-ओरिएंटेड प्रोग्रामिंग (आरओपी) एक कंप्यूटर सुरक्षा शोषण तकनीक है जो हमलावर को सुरक्षा सुरक्षा की उपस्थिति में कोड निष्पादित करने की अनुमति देती है।[1][2] जैसे निष्पादन योग्य स्थान सुरक्षा और कोड हस्ताक्षर।[3]

इस तकनीक में, एक हमलावर प्रोग्राम नियंत्रण प्रवाह को हाइजैक करने के लिए कॉल स्टैक पर नियंत्रण प्राप्त करता है और फिर सावधानी से चुने गए मशीन निर्देश अनुक्रमों को निष्पादित करता है जो पहले से ही मशीन की मेमोरी में मौजूद होते हैं, जिन्हें गैजेट कहा जाता है।[4][nb 1]प्रत्येक गैजेट आमतौर पर वापसी निर्देश में समाप्त होता है और मौजूदा प्रोग्राम और/या साझा लाइब्रेरी कोड के भीतर एक सबरूटीन में स्थित होता है।[nb 1]एक साथ बंधे हुए, ये गैजेट एक हमलावर को सरल हमलों को विफल करने वाली सुरक्षा का उपयोग करने वाली मशीन पर मनमाना संचालन करने की अनुमति देते हैं।

पृष्ठभूमि

कॉल स्टैक का एक उदाहरण लेआउट। सबरूटीन DrawLine द्वारा बुलाया गया है DrawSquare. ध्यान दें कि इस डायग्राम में स्टैक ऊपर की ओर बढ़ रहा है।

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

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

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

रिटर्न-इन-लाइब्रेरी तकनीक

See also: Return-to-libc attack

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

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


उधार लिया गया कोड हिस्सा

x64 | 64-बिट x86 प्रोसेसर का उदय अपने साथ सबरूटीन कॉलिंग कन्वेंशन में बदलाव लाया, जिसके लिए स्टैक के बजाय प्रोसेसर रजिस्टर में पारित होने के लिए फ़ंक्शन के पहले तर्क की आवश्यकता थी। इसका मतलब यह था कि एक हमलावर केवल बफर ओवररन शोषण के माध्यम से कॉल स्टैक में हेरफेर करके वांछित तर्कों के साथ लाइब्रेरी फ़ंक्शन कॉल सेट नहीं कर सकता था। साझा लाइब्रेरी डेवलपर्स ने उन लाइब्रेरी फ़ंक्शंस को हटाना या प्रतिबंधित करना भी शुरू कर दिया, जो किसी हमलावर के लिए विशेष रूप से उपयोगी कार्य करते थे, जैसे कि सिस्टम कॉल रैपर। नतीजतन, रिटर्न-इन-लाइब्रेरी हमलों को सफलतापूर्वक माउंट करना अधिक कठिन हो गया।

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

हमला

रिटर्न-ओरिएंटेड प्रोग्रामिंग उधार कोड चंक्स दृष्टिकोण पर बनाता है और लूप (कंप्यूटिंग) और सशर्त शाखाओं सहित हमलावर को ट्यूरिंग पूर्ण कार्यक्षमता प्रदान करने के लिए इसका विस्तार करता है।[9][10] दूसरा तरीका रखो, रिटर्न-ओरिएंटेड प्रोग्रामिंग एक पूरी तरह कार्यात्मक भाषा प्रदान करती है जिसका उपयोग एक हमलावर किसी समझौता मशीन को वांछित ऑपरेशन करने के लिए कर सकता है। होवव शाचम ने 2007 में तकनीक प्रकाशित की[11] और प्रदर्शित किया कि कैसे सी मानक लाइब्रेरी से जुड़े लक्ष्य एप्लिकेशन के खिलाफ रिटर्न-ओरिएंटेड प्रोग्रामिंग का उपयोग करके सभी महत्वपूर्ण प्रोग्रामिंग निर्माणों का अनुकरण किया जा सकता है और एक शोषक बफर ओवररन भेद्यता शामिल है।

वापसी-उन्मुख प्रोग्रामिंग हमला अभिव्यंजक शक्ति और रक्षात्मक उपायों के प्रतिरोध दोनों में चर्चा किए गए अन्य हमले प्रकारों से बेहतर है। साझा पुस्तकालयों से संभावित रूप से खतरनाक कार्यों को पूरी तरह से हटाने सहित ऊपर वर्णित प्रति-शोषण तकनीकों में से कोई भी रिटर्न-उन्मुख प्रोग्रामिंग हमले के खिलाफ प्रभावी नहीं है।

=== x86-आर्किटेक्चर === पर हालांकि विभिन्न प्रकार के आर्किटेक्चर पर रिटर्न-ओरिएंटेड प्रोग्रामिंग हमले किए जा सकते हैं,[11]Shacham का पेपर और अधिकांश अनुवर्ती कार्य Intel x86 आर्किटेक्चर पर केंद्रित हैं। x86 आर्किटेक्चर एक वेरिएबल-लेंथ जटिल निर्देश सेट कंप्यूटिंग इंस्ट्रक्शन सेट है। x86 पर रिटर्न-ओरिएंटेड प्रोग्रामिंग इस तथ्य का लाभ उठाती है कि निर्देश सेट बहुत सघन है, अर्थात, बाइट्स के किसी भी यादृच्छिक क्रम को x86 निर्देशों के कुछ वैध सेट के रूप में व्याख्या करने की संभावना है।

इसलिए एक opcode की खोज करना संभव है जो नियंत्रण प्रवाह को बदलता है, विशेष रूप से रिटर्न इंस्ट्रक्शन (0xC3) और फिर पूर्ववर्ती बाइट्स के लिए बाइनरी में पीछे की ओर देखें जो संभवतः उपयोगी निर्देश बनाते हैं। निर्देश गैजेट के इन सेटों को पहले गैजेट के पहले निर्देश के पते के साथ, एक बफर ओवररन शोषण के माध्यम से रिटर्न एड्रेस को ओवरराइट करके जंजीर से बांधा जा सकता है। इसके बाद बाद के गैजेट्स का पहला पता स्टैक पर क्रमिक रूप से लिखा जाता है। पहले गैजेट के समापन पर, एक वापसी निर्देश निष्पादित किया जाएगा, जो स्टैक से अगले गैजेट के पते को पॉप करेगा और उस पर कूद जाएगा। उस गैजेट के समापन पर, श्रृंखला तीसरे के साथ जारी रहती है, और इसी तरह। छोटे अनुदेश अनुक्रमों का पीछा करके, एक हमलावर पूर्व-मौजूदा पुस्तकालय कोड से मनमाना कार्यक्रम व्यवहार उत्पन्न करने में सक्षम होता है। Shacham का दावा है कि किसी भी पर्याप्त मात्रा में कोड (सी मानक पुस्तकालय सहित, लेकिन सीमित नहीं) दिया गया है, ट्यूरिंग-पूर्ण कार्यक्षमता के लिए पर्याप्त गैजेट मौजूद होंगे।[11]

गैजेट का पता लगाने की प्रक्रिया को स्वचालित करने और बाइनरी के खिलाफ हमले के निर्माण में मदद के लिए एक स्वचालित उपकरण विकसित किया गया है।[12] ROPgadget के रूप में जाना जाने वाला यह उपकरण, संभावित उपयोगी गैजेट्स की तलाश में एक बाइनरी के माध्यम से खोज करता है, और उन्हें एक हमले के पेलोड में इकट्ठा करने का प्रयास करता है जो हमलावर से मनमाना आदेश स्वीकार करने के लिए एक खोल पैदा करता है।

=== एड्रेस स्पेस लेआउट रैंडमाइजेशन === पर एड्रेस स्पेस लेआउट रैंडमाइजेशन में भी कमजोरियां हैं। शाचम एट अल। के पेपर के अनुसार,[13] 32-बिट आर्किटेक्चर पर ASLR एड्रेस रेंडमाइजेशन के लिए उपलब्ध बिट्स की संख्या से सीमित है। 32 एड्रेस बिट्स में से केवल 16 रैंडमाइजेशन के लिए उपलब्ध हैं, और 16 बिट्स एड्रेस रैंडमाइजेशन को मिनटों में ब्रूट फोर्स अटैक से हराया जा सकता है। 64-बिट आर्किटेक्चर अधिक मजबूत हैं, 64 बिट्स में से 40 रैंडमाइजेशन के लिए उपलब्ध हैं। 40-बिट रेंडमाइजेशन के लिए क्रूर बल का हमला संभव है, लेकिन किसी का ध्यान नहीं जाने की संभावना नहीं है[citation needed]. ब्रूट फ़ोर्स अटैक के अलावा, Randomized_algorithm#Derandomization के लिए तकनीकें मौजूद हैं।

यहां तक ​​​​कि सही यादृच्छिककरण के साथ, यदि स्मृति सामग्री का कोई रिसाव होता है तो यह रनटाइम पर लाइब्रेरी (कंप्यूटिंग) # साझा पुस्तकालयों के उदाहरण के आधार पते की गणना करने में मदद करेगा।[14]


वापसी निर्देश के उपयोग के बिना

चेकोवे एट अल के पेपर के अनुसार,[15] रिटर्न इंस्ट्रक्शन (x86 पर 0xC3) का उपयोग किए बिना x86 और ARM आर्किटेक्चर पर रिटर्न-ओरिएंटेड-प्रोग्रामिंग करना संभव है। इसके बजाय उन्होंने सावधानी से तैयार किए गए निर्देश अनुक्रमों का उपयोग किया जो पहले से ही मशीन की मेमोरी में रिटर्न निर्देश की तरह व्यवहार करने के लिए मौजूद हैं। एक वापसी निर्देश के दो प्रभाव होते हैं: सबसे पहले, यह स्टैक के शीर्ष पर चार-बाइट मान को पढ़ता है, और निर्देश सूचक को उस मान पर सेट करता है, और दूसरा, यह स्टैक सूचक मान को चार से बढ़ाता है (एक पॉप ऑपरेशन के बराबर) . X86 आर्किटेक्चर पर, jmp और पॉप निर्देशों के क्रम वापसी निर्देश के रूप में कार्य कर सकते हैं। एआरएम पर, लोड और शाखा निर्देशों के अनुक्रम वापसी निर्देश के रूप में कार्य कर सकते हैं।

चूंकि यह नया दृष्टिकोण वापसी निर्देश का उपयोग नहीं करता है, इसका रक्षा के लिए नकारात्मक प्रभाव पड़ता है। जब एक रक्षा कार्यक्रम न केवल कई रिटर्न बल्कि कई जंप निर्देशों के लिए भी जांच करता है, तो इस हमले का पता लगाया जा सकता है।

बचाव

जी-मुक्त

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


पता स्थान लेआउट यादृच्छिकीकरण

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

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

KBouncer द्वारा लिया गया एक अन्य दृष्टिकोण, ऑपरेटिंग सिस्टम को यह सत्यापित करने के लिए संशोधित करता है कि रिटर्न निर्देश वास्तव में कॉल निर्देश के तुरंत बाद नियंत्रण प्रवाह को एक स्थान पर वापस भेज देते हैं। यह गैजेट की श्रृंखलाबद्धता को रोकता है, लेकिन भारी प्रदर्शन दंड वहन करता है,[clarification needed] और जंप-उन्मुख प्रोग्रामिंग हमलों के खिलाफ प्रभावी नहीं है जो रिटर्न के बजाय जंप और अन्य नियंत्रण-प्रवाह-संशोधित निर्देशों को बदलते हैं।[21]


बाइनरी कोड रैंडमाइजेशन

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

सेहोप

माइक्रोसॉफ्ट-विशिष्ट अपवाद हैंडलिंग तंत्र#एसईएच ओवरराइट प्रोटेक्शन विंडोज की एक विशेषता है जो सबसे आम स्टैक ओवरफ्लो हमलों से बचाता है, विशेष रूप से एक संरचित अपवाद हैंडलर पर हमलों के खिलाफ।

नियंत्रण प्रवाह हमलों के खिलाफ

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


रिटर्न-ओरिएंटेड रूटकिट्स के खिलाफ

2010 में, जिन्कू ली एट अल। प्रस्तावित[24] कि एक उपयुक्त रूप से संशोधित संकलक प्रत्येक को बदलकर रिटर्न-उन्मुख गैजेट को पूरी तरह से समाप्त कर सकता है call f निर्देश क्रम के साथ pushl $index; jmp f और प्रत्येक ret निर्देश क्रम के साथ popl %reg; jmp table(%reg), कहाँ table कार्यक्रम में सभी वैध वापसी पतों के एक अपरिवर्तनीय सारणीकरण का प्रतिनिधित्व करता है और index उस तालिका में एक विशिष्ट अनुक्रमणिका का प्रतिनिधित्व करता है।[24]: 5–6  यह एक रिटर्न-उन्मुख गैजेट के निर्माण को रोकता है जो किसी फ़ंक्शन के अंत से सीधे किसी अन्य फ़ंक्शन के बीच में किसी मनमाने पते पर लौटता है; इसके बजाय, गैजेट केवल वैध रिटर्न पतों पर वापस आ सकते हैं, जो उपयोगी गैजेट बनाने की कठिनाई को काफी बढ़ा देता है। ली एट अल। दावा किया कि हमारी वापसी संकेत तकनीक अनिवार्य रूप से रिटर्न-ओरिएंटेड प्रोग्रामिंग को रिटर्न-इन-लिबक की पुरानी शैली में वापस सामान्य करती है।[24]उनके प्रूफ-ऑफ-कॉन्सेप्ट कंपाइलर में कुछ मशीन निर्देशों से निपटने के लिए एक पीपहोल अनुकूलन चरण शामिल था, जिसमें उनके ऑपकोड या तत्काल ऑपरेंड में रिटर्न ओपोड शामिल होता है,[24]जैसे कि movl $0xC3, %eax.

सूचक प्रमाणीकरण कोड (पीएसी)

ARMv8.3-A आर्किटेक्चर हार्डवेयर स्तर पर एक नई सुविधा पेश करता है जो विशेष रूप से डिज़ाइन किए गए ट्वीकेबल ब्लॉक सिफर का उपयोग करके पॉइंटर एड्रेस स्पेस में अप्रयुक्त बिट्स का लाभ उठाता है।[25][26] जो एक स्थानीय संदर्भ मूल्य (जैसे, स्टैक पॉइंटर) के साथ संयुक्त रूप से वांछित मान (आमतौर पर, एक वापसी पता) पर हस्ताक्षर करता है।

एक संवेदनशील ऑपरेशन करने से पहले (यानी, सहेजे गए पॉइंटर पर वापस लौटना) गलत संदर्भ में छेड़छाड़ या उपयोग का पता लगाने के लिए हस्ताक्षर की जाँच की जा सकती है (उदाहरण के लिए, एक ट्रैम्पोलिन संदर्भ से सहेजे गए वापसी पते का लाभ उठाना)।

विशेष रूप से iPhones में उपयोग किए जाने वाले Apple A12 चिप्स ARMv8.3 में अपग्रेड किए गए हैं और PAC का उपयोग करते हैं। लिनक्स को 2020 में जारी संस्करण 5.7 में कर्नेल के भीतर सूचक प्रमाणीकरण के लिए समर्थन प्राप्त हुआ; उपयोगकर्ता अंतरिक्ष अनुप्रयोगों के लिए समर्थन 2018 में जोड़ा गया था।[27] 2022 में, MIT के शोधकर्ताओं ने PAC के खिलाफ एक साइड-चैनल हमले को PACMAN करार दिया।[28]


यह भी देखें

टिप्पणियाँ

  1. ↑ 1.0 1.1 Some authors use the term gadget in a somewhat different way and refer to it as mere chunks of program logic or short sequences of opcodes crafted to perform some desired action.[29]


संदर्भ

  1. ↑ Vázquez, Hugo (2007-10-01). "Check Point Secure Platform Hack" (PDF). Pentest (in English). Barcelona, Spain: Pentest Consultores. p. 219.
  2. ↑ "Thread: CheckPoint Secure Platform Multiple Buffer Overflows". The Check Point User Group.
  3. ↑ Shacham, Hovav; Buchanan, Erik; Roemer, Ryan; Savage, Stefan. "Return-Oriented Programming: Exploits Without Code Injection". Retrieved 2009-08-12.
  4. ↑ Buchanan, E.; Roemer, R.; Shacham, H.; Savage, S. (October 2008). "When Good Instructions Go Bad: Generalizing Return-Oriented Programming to RISC" (PDF). Proceedings of the 15th ACM conference on Computer and communications security - CCS '08. pp. 27–38. doi:10.1145/1455770.1455776. ISBN 978-1-59593-810-7. S2CID 11176570.
  5. ↑ Microsoft Windows XP SP2 Data Execution Prevention
  6. ↑ Solar Designer, Return-into-lib(c) exploits, Bugtraq
  7. ↑ Nergal, Phrack 58 Article 4, return-into-lib(c) exploits
  8. ↑ Sebastian Krahmer, x86-64 buffer overflow exploits and the borrowed code chunks exploitation technique, September 28, 2005
  9. ↑ Abadi, M. N.; Budiu, M.; Erlingsson, Ú.; Ligatti, J. (November 2005). "Control-Flow Integrity: Principles, Implementations, and Applications". Proceedings of the 12th ACM conference on Computer and communications security - CCS '05. pp. 340–353. doi:10.1145/1102120.1102165. ISBN 1-59593-226-7. S2CID 3339874.
  10. ↑ Abadi, M. N.; Budiu, M.; Erlingsson, Ú.; Ligatti, J. (October 2009). "Control-flow integrity principles, implementations, and applications". ACM Transactions on Information and System Security. 13: 1–40. doi:10.1145/1609956.1609960. S2CID 207175177.
  11. ↑ 11.0 11.1 11.2 Shacham, H. (October 2007). "The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86)". Proceedings of the 14th ACM conference on Computer and communications security - CCS '07. pp. 552–561. doi:10.1145/1315245.1315313. ISBN 978-1-59593-703-2. S2CID 11639591.
  12. ↑ Jonathan Salwan and Allan Wirth, ROPgadget - Gadgets finder and auto-roper
  13. ↑ [Shacham et al., 2004] Hovav Shacham, Matthew Page, Ben Pfaff, Eu-Jin Goh, Nagendra Modadugu, and Dan Boneh. On the effectiveness of address-space randomization. In Proceedings of the 11th ACM conference on Computer and Communications Security (CCS), 2004.
  14. ↑ [Bennett et al., 2013] James Bennett, Yichong Lin, and Thoufique Haq. The Number of the Beast, 2013. https://www.fireeye.com/blog/threat-research/2013/02/the-number-of-the-beast.html
  15. ↑ CHECKOWAY, S., DAVI, L., DMITRIENKO, A., SADEGHI, A.-R., SHACHAM, H., AND WINANDY, M. 2010. Return-oriented programming without returns. In Proceedings of CCS 2010, A. Keromytis and V. Shmatikov, Eds. ACM Press, 559–72
  16. ↑ ONARLIOGLU, K., BILGE, L., LANZI, A., BALZAROTTI, D., AND KIRDA, E. 2010. G-Free: Defeating return-oriented programming through gadget-less binaries. In Proceedings of ACSAC 2010, M. Franz and J. McDermott, Eds. ACM Press, 49–58.
  17. ↑ Skowyra, R.; Casteel, K.; Okhravi, H.; Zeldovich, N.; Streilein, W. (October 2013). "Systematic Analysis of Defenses against Return-Oriented Programming" (PDF). Research in Attacks, Intrusions, and Defenses. Lecture Notes in Computer Science. Vol. 8145. pp. 82–102. doi:10.1007/978-3-642-41284-4_5. ISBN 978-3-642-41283-7. Archived from the original (PDF) on 2014-02-22.
  18. ↑ Venkat, Ashish; Shamasunder, Sriskanda; Shacham, Hovav; Tullsen, Dean M. (2016-01-01). "HIPStR: Heterogeneous-ISA Program State Relocation". Proceedings of the Twenty-First International Conference on Architectural Support for Programming Languages and Operating Systems. ASPLOS '16. New York, NY, USA: ACM: 727–741. doi:10.1145/2872362.2872408. ISBN 9781450340915. S2CID 7853786.
  19. ↑ Hiser, J.; Nguyen-Tuong, A.; Co, M.; Hall, M.; Davidson, J. W. (May 2012). "ILR: Where'd My Gadgets Go?". 2012 IEEE Symposium on Security and Privacy. pp. 571–585. doi:10.1109/SP.2012.39. ISBN 978-1-4673-1244-8. S2CID 15696223.
  20. ↑ US 9135435, Venkat, Ashish; Krishnaswamy, Arvind & Yamada, Koichi et al., "Binary translator driven program state relocation", published 2015-09-15, assigned to Intel Corp. 
  21. ↑ Vasilis Pappas. kBouncer: Efficient and Transparent ROP Mitigation. April 2012.
  22. ↑ US application 2019347385, Shelly, Asaf, "Security methods and systems by code mutation", published 2019-11-14 , since abandoned.
  23. ↑ FRANCILLON, A., PERITO, D., AND CASTELLUCCIA, C. 2009. Defending embedded systems against control flow attacks. In Proceedings of SecuCode 2009, S. Lachmund and C. Schaefer, Eds. ACM Press, 19–26.
  24. ↑ 24.0 24.1 24.2 24.3 Jinku LI, Zhi WANG, Xuxian JIANG, Mike GRACE, and Sina BAHRAM. Defeating return-oriented rootkits with "return-less" kernels. In Proceedings of EuroSys 2010, edited by G. Muller. ACM Press, 195–208.
  25. ↑ Avanzi, Roberto (2016). The QARMA Block Cipher Family (PDF). IACR Transactions on Symmetric Cryptology (ToSC). Vol. 17 (published 2017-03-08). pp. 4–44. doi:10.13154/tosc.v2017.i1.4-44. Archived from the original (PDF) on 2020-05-13.
  26. ↑ Qualcomm Product Security. "Pointer Authentication on ARMv8.3" (PDF). Qualcomm Technologies Inc. Archived (PDF) from the original on 2020-06-06. Retrieved 2020-06-16. Thus, we designed QARMA, a new family of lightweight tweakable block ciphers.
  27. ↑ "Linux 5.7 For 64-bit ARM Brings In-Kernel Pointer Authentication, Activity Monitors - Phoronix". www.phoronix.com. Retrieved 2020-03-31.
  28. ↑ Ravichandran, Joseph; Na, Weon Taek; Lang, Jay; Yan, Mengjia (June 2022). "PACMAN: attacking ARM pointer authentication with speculative execution". Proceedings of the 49th Annual International Symposium on Computer Architecture. Association for Computing Machinery. doi:10.1145/3470496.3527429.
  29. ↑ Cha, Sang Kil; Pak, Brian; Brumley, David; Lipton, Richard Jay (2010-10-08) [2010-10-04]. Platform-Independent Programs (PDF). Proceedings of the 17th ACM conference on Computer and Communications Security (CCS'10). Chicago, Illinois, USA: Carnegie Mellon University, Pittsburgh, Pennsylvania, USA / Georgia Institute of Technology, Atlanta, Georgia, USA. pp. 547–558. doi:10.1145/1866307.1866369. ISBN 978-1-4503-0244-9. Archived (PDF) from the original on 2022-05-26. Retrieved 2022-05-26. [1] (12 pages) (See also: [2]) (NB. Uses the term gadget for chunks of program logic, in this case divided into gadget header and gadget body.)


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=वापसी-उन्मुख_प्रोग्रामिंग&oldid=125496’