ओपनबीएसडी के डब्ल्यू^एक्स सुरक्षा तंत्र को मजबूत करने की योजना

थियो डी राडट साझा W^X (Write XOR Execute) मेमोरी सुरक्षा तंत्र को मजबूत करने की योजना है। तंत्र का सार यह है कि प्रक्रिया स्मृति पृष्ठों को लेखन और निष्पादन के लिए एक साथ एक्सेस नहीं किया जा सकता है। इस प्रकार, लेखन अक्षम होने के बाद ही कोड निष्पादित किया जा सकता है, और मेमोरी पेज पर लिखना निष्पादन अक्षम होने के बाद ही संभव है। W^X तंत्र उपयोगकर्ता-स्थान अनुप्रयोगों को स्टैक ओवरफ़्लो सहित सामान्य बफर ओवरफ़्लो हमलों से बचाने में मदद करता है, और OpenBSD में सक्रिय है डिफ़ॉल्ट रूप से.

W^X पर काम की शुरुआत से, यह स्पष्ट था कि यह एक लंबी सड़क थी, क्योंकि JIT का उपयोग करने वाले अनुप्रयोगों की एक महत्वपूर्ण संख्या थी। JIT कार्यान्वयन को तीन श्रेणियों में विभाजित किया जा सकता है:

• सिस्टम कॉल की "लागत" को स्वीकार करते हुए, W और X स्थितियों के बीच मेमोरी स्विच करना mप्रोटेक्ट.
• एक ही मेमोरी की W और X मैपिंग की जोड़ी के बीच उपनाम बनाना।
• सबसे "गंदा" विकल्प वे हैं जिनके लिए W|X मेमोरी मॉडल की आवश्यकता होती है जो एक साथ रिकॉर्डिंग और निष्पादन की अनुमति देता है।

वर्तमान में, तीसरे विकल्प का उपयोग करने वाले काफी कम प्रोग्राम हैं और पहले और दूसरे का उपयोग करने वाले प्रोग्राम अधिक हैं। हालाँकि, चूँकि W|X JIT (मुख्य रूप से क्रोमियम और इरिडम) के साथ प्रोग्राम चलाना आवश्यक था, एक "wxallowed" फ़ाइल सिस्टम माउंट विकल्प जोड़ा गया था, जो लेखन और निष्पादन दोनों के लिए मेमोरी को एक साथ उपयोग करने की अनुमति देता था, यदि निष्पादन योग्य ELF फ़ाइल को "wxneeded" मार्कर के साथ चिह्नित किया गया है, और एप्लिकेशन स्वयं तंत्र का उपयोग करके अतिरिक्त रूप से संरक्षित थे प्रतिज्ञा и खोलना उपयोग की गई सिस्टम कॉल की सूची और एप्लिकेशन के लिए उपलब्ध फ़ाइल सिस्टम के हिस्सों को क्रमशः सीमित करने के लिए।

ऐसे अनुप्रयोगों में कमजोरियों के दोहन को और अधिक जटिल बनाने के लिए, तंत्र में एक अतिरिक्त बदलाव प्रस्तावित है MAP_स्टैक, जो जांचता है कि सिस्टम कॉल को लिखने योग्य मेमोरी पेज से निष्पादित किया जा रहा है या नहीं। यदि पृष्ठ लिखने योग्य है, तो प्रक्रिया को जबरन समाप्त कर दिया जाता है। इस तरह, एक हमलावर सिस्टम कॉल का फायदा उठाने में सक्षम नहीं होगा और उसे JIT कार्यान्वयन में आवश्यक गैजेट खोजने का प्रयास करने के लिए मजबूर किया जाएगा, या सीधे अंदर सिस्टम कॉल स्टब्स का पता लगाने का अधिक कठिन काम भी कर सकता है। गलती से libc लिंक हो गया.

क्रोम/इरिडियम प्रक्रियाएं पहले से ही प्रतिज्ञा और अनावरण का उपयोग करके काफी विश्वसनीय रूप से संरक्षित हैं, लेकिन उदाहरण के लिए, राइट (2) सिस्टम कॉल का उपयोग करने की क्षमता को हटाने से स्पष्ट रूप से कुछ लाभ होता है, क्योंकि यह हमलावर के लिए अतिरिक्त कठिनाइयां पैदा करता है। हालाँकि, यदि JIT कार्यान्वयन W|X मेमोरी से मूल सिस्टम कॉल का उपयोग करता है तो कठिनाइयाँ भी उत्पन्न हो सकती हैं। हालाँकि, यह आशा करने का कारण है कि ऐसा नहीं होगा, क्योंकि एबीआई को कई बार बदला गया है, लेकिन किसी ने कभी भी समस्या की सूचना नहीं दी है।

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

क्रोम/इरिडियम में मोड की उपस्थिति के बारे में संबंधित समाचार थियो की ओर से एक अलग टिप्पणी के योग्य है JITरहित. उनके दृष्टिकोण से, यह कुछ उपयोग मॉडलों के लिए स्वीकार्य है, लेकिन संभवतः सभी के लिए नहीं, क्योंकि यह मोड स्पष्ट रूप से प्रोसेसर पर लोड बढ़ा देगा। वर्तमान में, यदि आप /usr/local के लिए "wxallowed" को अक्षम करते हैं तो क्रोम अधिकतर काम करेगा, हालांकि कुछ एक्सटेंशन के साथ समस्याएं हो सकती हैं (घोस्टरी एक उदाहरण है)। एक तरह से या किसी अन्य, थियो को उम्मीद है कि निकट भविष्य में JITless मोड में पूर्ण कार्य को पूरी तरह से चालू स्थिति में लाया जाएगा।

स्रोत: opennet.ru