OpenBSD को W^X सुरक्षा संयन्त्रलाई सुदृढ बनाउने योजनाहरू

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

W^X मा काम सुरु भएदेखि, यो स्पष्ट थियो कि यो लामो बाटो थियो, किनकि त्यहाँ JIT प्रयोग गर्ने अनुप्रयोगहरूको उल्लेखनीय संख्या थियो। JIT कार्यान्वयनलाई तीन वर्गमा विभाजन गर्न सकिन्छ:

• W र X राज्यहरू बीच मेमोरी स्विच गर्दै, प्रणाली कलको "लागत" स्वीकार गर्दै mpprotect.
• एउटै मेमोरीको W र X म्यापिङहरू बीच उपनामहरू सिर्जना गर्दै।
• सबैभन्दा "फोहोर" विकल्पलाई W|X मेमोरी मोडेल चाहिन्छ जसले एकसाथ रेकर्डिङ र कार्यान्वयन गर्न अनुमति दिन्छ।

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

त्यस्ता अनुप्रयोगहरूमा कमजोरीहरूको शोषणलाई थप जटिल बनाउन, संयन्त्रमा थप प्रस्ताव गरिएको छ। MAP_STACCK, जसले प्रणाली कल लेख्न योग्य मेमोरी पृष्ठबाट कार्यान्वयन भइरहेको छ कि छैन भनेर जाँच गर्दछ। यदि पृष्ठ लेख्न योग्य छ भने, प्रक्रिया समाप्त गर्न बाध्य छ। यस तरिकाले, एक आक्रमणकारीले प्रणाली कलहरू शोषण गर्न सक्षम हुनेछैन र JIT कार्यान्वयनमा आवश्यक ग्याजेटहरू फेला पार्न प्रयास गर्न वा सिधै भित्र प्रणाली कल स्टबहरू पत्ता लगाउन अझ गाह्रो काम गर्न बाध्य हुनेछ। संयोगवश लिङ्क गरिएको libc.

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

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

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

स्रोत: opennet.ru