ओपनबीएसडी को एक सुरक्षित ओएस के रूप में तैनात किया गया है। हालांकि, पिछले कुछ महीनों में, सिस्टम में कई कमजोरियां पाई गई हैं। बेशक, इस बारे में कुछ भी असाधारण नहीं है। हालांकि कुछ कमजोरियां काफी असामान्य हैं। आप आलोचनात्मक भी कह सकते हैं। OpenBSD डेवलपर्स के पास सुरक्षा सुनिश्चित करने के लिए कई दिशानिर्देश हैं। यहाँ उनमें से दो हैं:

गलतियों से बचें;
त्रुटियों का जोखिम कम करें।

हर कोई इस बात से सहमत नहीं है कि ये सिद्धांत सुरक्षित सिस्टम बनाने के लिए पर्याप्त हैं। मुझे ऐसा लगता है कि यह अध्ययन करने के लिए समझ में आता है कि क्या OpenBSD दृष्टिकोण काम करता है, या यदि यह शुरू में बर्बाद होता है।

चित्रण के लिए, मैंने सभी का चयन नहीं किया, लेकिन केवल कुछ दिलचस्प कीड़े जो गलती से हमारी बातचीत के विषय के साथ मेल खाते हैं।

परिवाद

प्रमाणन कार्यों argv की जाँच के बिना सहायकों चलाते हैं। रिपोर्ट । पैच ।

यह एक आश्चर्यजनक सरल गलती है, लेकिन कोड समीक्षा के दौरान यह संभवतः बहुत स्पष्ट नहीं था। यह मुझे लगता है, आंशिक रूप से, कुछ भ्रम का कारण इनपुट डेटा की जांच के लिए कौन जिम्मेदार है। आप इसमें शामिल प्रत्येक तीन घटकों को कॉल कर सकते हैं: एक प्रोग्राम, एक लाइब्रेरी, या login_passwd - और यह मान लेना उचित है कि कोई और व्यक्ति जाँच कर रहा है। अंत में, मुझे लगता है कि पुस्तकालय को दोषी पाया गया था, क्योंकि यह उसके लिए था कि एक पैच दिखाई दिया, लेकिन व्यक्तिगत रूप से मुझे पहली नज़र में इसका कोड स्पष्ट रूप से गलत नहीं लगता है।

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

यदि केर्बेरोस कोड को अच्छी तरह से साफ किया गया था, तो प्रमाणीकरण बग अभी भी बना रहेगा (arvv पार्सिंग के साथ कुछ अन्य संबंधित समस्याएं थीं), लेकिन इसका प्रभाव निश्चित रूप से बहुत कम हो जाएगा।

सुरक्षा के संदर्भ में argv को सही ढंग से पार्स करना आसान नहीं है। कई तार्किक युक्तियां और दृष्टिकोण यहां काम नहीं करते हैं। मैं केवल यह नोट करूंगा कि यह भेद्यता के बाद पॉप अप हुआUnix / Linux / POSIX पर फ़ाइल नामों के साथ समस्या की एक और चर्चा , हालांकि प्रमुख माइनस (हाइफ़न) वास्तव में फ़ाइल नाम को संदर्भित नहीं करता है।

ld.so

खराब पर्यावरण चर को ld.so कोड से नहीं हटाया गया है। रिपोर्ट । पैच ।

मेमोरी एरर जैसा कुछ। लेकिन नहीं। यहां बग को एक ऑपरेशन की सफलता से जोड़ना है - पर्यावरण चर को विभाजित करना - उस चर को हटाना। बहुत भरोसा।

बेशक, विभिन्न टाइपिंग सिस्टम के प्रस्तावक आश्वासन देंगे कि वे इन कार्यों को सही क्रम में संसाधित करेंगे, लेकिन इस तथ्य से नहीं कि इससे मदद मिलेगी। सी कोड त्रुटि से निपटने की कमी के कारण दुर्घटनाग्रस्त नहीं हुआ या क्योंकि मेमोरी आवंटन त्रुटि अदृश्य बनी हुई है।

एफ़टीपी

ftp लोकल फाइल्स को रीडायरेक्ट करता है। रिपोर्ट । पैच ।

NetBSD ftp पुनर्निर्देशित बग लंबे समय से अनियंत्रित कार्यों का एक विशिष्ट उदाहरण है । और यहाँ फिर से वही गलती (सौभाग्य से, मामूली परिणामों के साथ)! दोस्तों, ठीक है, घर पर बैठो। अपने कार्यक्रमों में अतिरिक्त सुविधाएँ न जोड़ें।

से smtpd

smtpd कुछ प्रेषक पतों की जाँच नहीं कर सकता है। रिपोर्ट । पैच । टिप्पणी करें ।

मुझे लगता है कि गिल्स की टिप्पणी में सब कुछ कहा गया है, लेकिन मैं पृष्ठभूमि को याद दिलाऊंगा। एक बार, सभी मेल स्थानीय रूप से प्रत्येक उपयोगकर्ता के लिए / var / मेल में संग्रहीत किए गए थेmbox फ़ाइलों में। यह बहुत अच्छा नहीं है, क्योंकि नुकसान होने की संभावना होती है, यदि म्यू ईमेल को हटा देता है जबकि mda एक नया डिलीवर करता है (अन्य फ़ील्ड्स को विकृत करने जैसे अन्य मुद्दों का उल्लेख नहीं करने के लिए)। इसलिए, mbox फ़ाइल को लॉक करने की आवश्यकता है। लेकिन नेटवर्क फ़ाइल सिस्टम पर लॉकिंग मज़बूती से काम नहीं करता है। इसलिए लॉक करने के बजाय हम लॉक फाइल का इस्तेमाल करते हैं। हालांकि, आपको एक विशिष्ट अवरोधक प्रोटोकॉल पर एक समझौते पर आने की आवश्यकता है, क्योंकि उपयोगकर्ता एमबॉक्स फ़ाइलों का मालिक है, और रूट स्वयं निर्देशिका का मालिक है। इस प्रकार, वास्तव में एमबॉक्स फ़ाइल को संशोधित करने के लिए, आपको हर बार सेट्यूड हेल्पर फ़ंक्शन को चलाने की आवश्यकता होती है। खैर, यह पहली समस्या है। पुराने दिनों का एक और अवशेष एमडीए सेटिंग्स है, जिसका उपयोग न केवल एक कार्यक्रम के रूप में किया जा सकता है, बल्कि एक शेल पाइपलाइन के रूप में भी किया जा सकता है। लोग कुछ ऐसा लिख देते हैंspam-assassin | mail.mdaऔर तुम सिर्फ उस पर पारित नहीं हो सकता execve()।

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

इससे बचना उतना ही आसान लगता है जितना कि मेलडिर स्टोरेज फॉर्मेट में स्विच करना, लेकिन इसके लिए कई जगहों पर विभिन्न बदलावों की आवश्यकता होती है। मानक मुआ मेलइस प्रारूप को नहीं समझता है। मेरे लिए, mbox ने अपने जीवन को लंबा कर दिया है, लेकिन यह अभी भी बहुत से लोगों को सूट करता है, और अद्यतन प्रक्रिया पूरी तरह से पारदर्शी नहीं हो सकती है और स्वचालित रूप से काम नहीं करेगी।

smtpd पढ़ा

Smtpd में स्कोप के बाहर पढ़ने का उपयोग कमांड निष्पादित करने के लिए किया जा सकता है। रिपोर्ट । पैच ।

यह वास्तव में एक स्मृति सुरक्षा मुद्दा है। कुछ मज़ेदार स्टेटस बार भेजकर, दूरस्थ smtp सर्वर कमांड को निष्पादन के लिए smtpd कतार में इंजेक्ट कर सकता है। जब किसी ईमेल को पुनः वितरण के लिए कतार में लगाया जाता है, तो smtpd शीर्ष लेख में कुछ गंतव्य जानकारी जोड़ता है ताकि यह पता चल सके कि किस कमांड को निष्पादित करना है (ऊपर देखें)। यह हमला http अनुरोधों के "तस्करी" के समान है । यदि आप हेडर में अनपेक्षित कमांड के साथ "शिट" उत्पन्न कर सकते हैं, तो smtpd उन्हें निष्पादित करेगा जब आप पुनः वितरित करने का प्रयास करेंगे।

जैसा कि ऊपर, समस्याओं में से एक यह है कि smtpd के सबसे संवेदनशील हिस्से हमले की सतह के बहुत करीब हैं। यह मुझे लगता है कि वास्तविक समस्या यह है कि smtpd ईमेल डेटा के अंदर अपना मेटाडेटा संग्रहीत करता है। इस वजह से, सिंक हमले से एक पार्सिंग संभव हो जाता है। यदि सर्वर से उद्धृत प्रतिक्रिया डिलीवरी के निर्देशों के साथ फ़ाइल से पूरी तरह से अलग रखी गई थी, तो सीमाओं के बाहर पढ़ने से बहुत नुकसान नहीं होगा।

यह भेद्यता मेरे लिए सांकेतिक लगती है, क्योंकि यहां हमें विभिन्न स्तरों के भरोसे के साथ डेटा मिलाने का खतरा दिखाई देता है। इस खतरे पर कभी चर्चा नहीं हुई। और वह निश्चित रूप से है।

जाँच - परिणाम

बेशक, यह निष्कर्ष बहुत शुरुआत से स्पष्ट था, लेकिन हम इसके बारे में वैसे भी बात करेंगे।

मुझे लगता है कि इनमें से कुछ त्रुटियां यह प्रदर्शित करने में मदद करती हैं कि कैसे अप्रचलित इंटरफेस को हटाने और कोड जटिलता को कम करने जैसे सिद्धांत सुरक्षा के लिए महत्वपूर्ण हैं । अधिकांश भाग के लिए, विफलता इस तथ्य के कारण हुई कि इन सिद्धांतों का अंत तक पालन नहीं किया गया था, और इसलिए नहीं कि सिद्धांत स्वयं खराब या अस्थिर हैं। कुछ चीजें दृष्टि से बाहर फिसल रही हैं, लेकिन मैं इस बात से सहमत नहीं हूं कि डेवलपर्स को किसी प्रकार की अलौकिक सतर्कता की आवश्यकता है। बेकार सलाह देना आसान है, जैसे कि सावधान रहें, गलतियाँ न करें और git gud [कठबोली अभिव्यक्ति का अर्थ है 'अच्छा हो जाओ' ', "बेहतर होगा, जल्दी ठीक हो जाओ" - लगभग। ट्रांस।]। लेकिन मुझे लगता है कि OpenBSD में अधिक गंभीर समस्याएं हैं।

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

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

विशेषाधिकारों का पृथक्करण OpenBSD सुरक्षा का एक प्रमुख घटक है, और यह इंटरप्रोसेस संचार पर आधारित है। यह समझ में आता है कि क्षतिग्रस्त प्रक्रियाओं के साथ क्या समस्याएं पैदा हो सकती हैं। संरक्षित ब्राउज़र तेजी से सुरक्षा और बाधा हमलों को बढ़ा रहे हैं। विशेष रूप से, नेटवर्क कार्यों में मेमोरी भ्रष्टाचार के खिलाफ smtpd को संरक्षित किया जाना चाहिए। लेकिन जिस सहजता से वह माता-पिता की प्रक्रिया को नियंत्रित करने में सक्षम होता है वह चिंताजनक है।

अधिक सुरक्षित भाषा का उपयोग करके केवल एक गलती को रोका जा सकता है। हां, शायद, किसी प्रकार का कार्यक्रम मुहावरा है, जो कुछ मामलों में मदद कर सकता है यदि आप धार्मिक दृढ़ता के साथ इसका पालन करते हैं। लेकिन मुझे अभी तक यकीन नहीं है कि डिफ़ॉल्ट रूप से प्रत्येक प्रोग्रामर सही ढंग से सभी संगत इनवॉयस को एनकोड करेगा।

मेल सर्वर लिखना एक मुश्किल काम है। खासतौर पर अगर विरासत फ्रेम आपको तंग कर रहे हों।

यह OpenBSD सुरक्षा पर पुनर्विचार करने का समय है