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" फाइलसिस्टम माउंट पर्याय जोडला गेला, ज्यामुळे मेमरी लेखन आणि अंमलबजावणी या दोन्हीसाठी एकाच वेळी वापरली जाऊ शकते, जर एक्झिक्युटेबल ई.एल.एफ. फाइलला "wxneeded" मार्करने चिन्हांकित केले आहे, आणि ऍप्लिकेशन स्वतःच यंत्रणा वापरून संरक्षित केले आहेत. प्रतिज्ञा и अनावरण वापरलेल्या सिस्टीम कॉल्सची यादी आणि ऍप्लिकेशनसाठी उपलब्ध फाइल सिस्टमचे भाग मर्यादित करण्यासाठी.

अशा ऍप्लिकेशन्समधील असुरक्षिततेचे शोषण आणखी क्लिष्ट करण्यासाठी, यंत्रणा जोडण्याचा प्रस्ताव आहे MAP_STACK, जे लिहिण्यायोग्य मेमरी पृष्ठावरून सिस्टम कॉल कार्यान्वित केले जात आहे की नाही हे तपासते. पृष्ठ लिहिण्यायोग्य असल्यास, प्रक्रिया समाप्त करण्यास भाग पाडले जाते. अशा प्रकारे, आक्रमणकर्ता सिस्टम कॉल्सचा गैरफायदा घेऊ शकणार नाही आणि JIT अंमलबजावणीमध्ये आवश्यक गॅझेट शोधण्याचा प्रयत्न करण्यास भाग पाडले जाईल किंवा थेट आत सिस्टम कॉल स्टब शोधण्याचे अधिक कठीण काम देखील करू शकेल. चुकून libc लिंक केले.

क्रोम/इरिडियम प्रक्रिया आधीच तारण आणि अनावरण वापरून बर्‍यापैकी विश्वसनीयरित्या संरक्षित आहेत, परंतु वापरण्याची क्षमता काढून टाकणे, उदाहरणार्थ, लेखन(2) सिस्टम कॉलचा नक्कीच काही फायदा आहे, कारण यामुळे आक्रमणकर्त्यासाठी अतिरिक्त अडचणी निर्माण होतात. तथापि, JIT अंमलबजावणीने W|X मेमरीमधील नेटिव्ह सिस्टम कॉल्स वापरल्यास अडचणी देखील उद्भवू शकतात. तथापि, असे होणार नाही अशी आशा करण्याचे कारण आहे, कारण एबीआय अनेक वेळा बदलले गेले आहे, परंतु कोणीही समस्या नोंदवल्या नाहीत.

OpenBSD-वर्तमान शाखेच्या नियमित स्नॅपशॉट्समध्ये बदल आधीच उपलब्ध आहेत, स्वारस्य असलेल्या प्रत्येकाला चाचणीसाठी आमंत्रित केले आहे.

Chrome/Iridium मधील मोड दिसण्याविषयी संबंधित बातम्या Theo कडून वेगळ्या टिप्पणीसाठी पात्र आहेत JITless. त्याच्या दृष्टिकोनातून, हे काही वापर मॉडेलसाठी स्वीकार्य आहे, परंतु कदाचित सर्वांसाठी नाही, कारण या मोडमुळे प्रोसेसरवरील भार स्पष्टपणे वाढेल. सध्या, तुम्ही /usr/local साठी "wxallowed" अक्षम केल्यास, Chrome बहुतांशी कार्य करेल, जरी काही विस्तारांमध्ये समस्या असू शकतात (ghostery एक उदाहरण आहे). एक ना एक मार्ग, थिओला आशा आहे की नजीकच्या भविष्यात JITless मोडमध्ये पूर्ण कार्य पूर्णतः कार्यान्वित स्थितीत आणले जाईल.

स्त्रोत: opennet.ru