टीएल, डॉ । इस लेख में, हम उन सख्त योजनाओं का पता लगाते हैं, जो पांच लोकप्रिय लिनक्स वितरण पर बॉक्स से बाहर निकलती हैं। प्रत्येक के लिए, हमने डिफ़ॉल्ट कर्नेल कॉन्फ़िगरेशन लिया, सभी पैकेज डाउनलोड किए, और संलग्न बाइनरी फ़ाइलों में सुरक्षा योजनाओं का विश्लेषण किया। हम OpenSUSE 12.4, डेबियन 9, सेंटोस, आरएचईएल 6.10 और 7 के साथ-साथ उबंटू 14.04, 12.04 और 18.04 एलटीएस के वितरण पर विचार करते हैं।

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

सत्यापन से पता चला है कि ओएस और आवेदन स्तर पर उबंटू 18.04 में सबसे बड़ी सुरक्षा विधियां लागू की गई हैं, इसके बाद डेबियन 9. है, दूसरी ओर, ओपनसैट 12.4, सेंटोस 7 और आरएचईएल 7 में, बुनियादी सुरक्षा योजनाएं भी लागू की जाती हैं, और स्टैक टकराव की सुरक्षा को और भी व्यापक रूप से लागू किया जाता है। डिफ़ॉल्ट रूप से संकुल के अधिक सघन सेट के साथ।

परिचय

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

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

सीवीई और सुरक्षा

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

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


अंजीर। 1

यह चार्ट हमें क्या बताता है? क्या अधिक सीवीई का मतलब है कि एक वितरण दूसरे की तुलना में अधिक कमजोर है? कोई जवाब नहीं है। उदाहरण के लिए, इस लेख में आप देखेंगे कि डिबियन ने OpenSUSE या RedHat Linux की तुलना में अधिक कड़े सुरक्षा तंत्र लागू किए हैं, और फिर भी डेबियन के पास अधिक CVE है। हालांकि, वे जरूरी नहीं कि कमजोर सुरक्षा का मतलब है: यहां तक ​​कि सीवीई भी यह नहीं कहता है कि भेद्यता शोषक है । गंभीरता स्कोर इस बात का अंदाजा लगाता है कि भेद्यता का शोषण कितना संभावित है, लेकिन अंततः शोषण क्षमता काफी हद तक प्रभावित प्रणालियों में मौजूद संरक्षण पर निर्भर करती है, साथ ही हमलावरों के संसाधनों और क्षमताओं पर भी। इसके अलावा, सीवीई रिपोर्टों की कमी अन्य अपंजीकृत या अज्ञात कमजोरियों के बारे में कुछ नहीं कहती है। सीवीई में अंतर को सॉफ्टवेयर की गुणवत्ता से नहीं, बल्कि अन्य कारकों द्वारा समझाया जा सकता है, जिसमें परीक्षण के लिए आवंटित संसाधन, या उपयोगकर्ता आधार का आकार शामिल है। हमारे उदाहरण में, अधिक डेबियन सीवीई केवल यह संकेत दे सकता है कि डेबियन अधिक सॉफ्टवेयर पैकेज दे रहा है।

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


अंजीर। 2

कार्य

इस लेख में, हम निम्नलिखित प्रश्नों का उत्तर देना चाहते हैं:

• विभिन्न लिनक्स वितरणों की सुरक्षा क्या है? कर्नेल और उपयोगकर्ता अंतरिक्ष अनुप्रयोगों में कौन से रक्षा तंत्र मौजूद हैं?
  
• समय के साथ विभिन्न वितरणों के लिए सुरक्षा तंत्र को कैसे अपनाया जाता है?
  
• प्रत्येक वितरण के लिए संकुल और पुस्तकालयों की औसत निर्भरता क्या हैं?
  
• प्रत्येक बाइनरी के लिए क्या सुरक्षा लागू की जाती है?

वितरण चुनना

यह पता चला है कि वितरण प्रतिष्ठानों पर सटीक आंकड़े ढूंढना मुश्किल है, क्योंकि ज्यादातर मामलों में डाउनलोड की संख्या वास्तविक प्रतिष्ठानों की संख्या को इंगित नहीं करती है। हालांकि, यूनिक्स वेरिएंट सर्वर सिस्टम (वेब ​​सर्वर पर 69.2%, W3tech और अन्य स्रोतों के आंकड़ों के अनुसार) का बहुमत बनाते हैं, और उनकी हिस्सेदारी लगातार बढ़ रही है। इस प्रकार, हमारे अध्ययन के लिए, हमने Google क्लाउड प्लेटफ़ॉर्म पर बॉक्स से उपलब्ध वितरण पर ध्यान केंद्रित किया। विशेष रूप से, हमने निम्नलिखित OS को चुना:

वितरण / संस्करण	कोर	Bild
OpenSUSE 12.4	4.12.14-95.3-डिफ़ॉल्ट	# 1 एसएमपी बुध दिसंबर 5 06:00:48 यूटीसी 2018 (63a8d29)
डेबियन 9 (खिंचाव)	4.9.0-8-amd64	# 1 एसएमपी डेबियन 4.9.130-2 (2018-10-27)
सेंटोस 6.10	2.6.32-754.10.1.el6.x86_64	# 1 एसएमपी टीयू 15 जनवरी 17:07:28 यूटीसी 2019
सेंटोस 7	3.10.0-957.5.1.el7.x86_64	# 1 एसएमपी शुक्र फरवरी 1 14:54:57 यूटीसी 2019
Red Hat Enterprise Linux सर्वर 6.10 (सैंटियागो)	2.6.32-754.9.1.el6.x86_64	# 1 एसएमपी बुध नवंबर 21 15:08:21 ईएसटी 2018
Red Hat Enterprise Linux सर्वर 7.6 (Maipo)	3.10.0-957.1.3.el7.x86_64	# 1 एसएमपी थू नवंबर 15 17:36:42 यूटीसी 2018
Ubuntu 14.04 (भरोसेमंद तहर)	4.4.0-140-सामान्य	# 166 ~ 04/14/1-उबंटू एसएमपी सत नव 17 01:52:43 यूटीसी 20 ...
उबंटू 16.04 (ज़ेनियल ज़ेरुस)	4.15.0-1026-जीसीपी	# 27 ~ 16.04.1-Ubuntu SMP शुक्र 7 दिसंबर 09:59:47 UTC 2018
उबंटू 18.04 (बायोनिक बीवर)	4.15.0-1026-जीसीपी	# 27-उबटन एसएमपी थू दिसंबर 6 18:27:01 यूटीसी 2018

तालिका 1

के विश्लेषण

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

कर्नेल कॉन्फ़िगरेशन विश्लेषण

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





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

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

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

अनुप्रयोग विश्लेषण

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

वितरण

कुल में, हमने सभी वितरणों के लिए 361,556 पैकेज डाउनलोड किए, केवल डिफ़ॉल्ट दर्पणों से ही पैकेज निकाले। हमने ईएलएफ निष्पादन योग्य फ़ाइलों के बिना पैकेजों को नजरअंदाज कर दिया, जैसे कि स्रोत कोड, फोंट, आदि। फ़िल्टर करने के बाद, 129 569 पैकेज कुल 584 457 बाइनरी फ़ाइलों से युक्त थे। वितरण के बीच पैकेज और फ़ाइलों का वितरण अंजीर में दिखाया गया है। 3।


अंजीर। 3

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


अंजीर। 4

लगभग सभी वितरणों में, 60% पैकेजों में कम से कम 10 निर्भरताएं होती हैं। इसके अलावा, कुछ पैकेजों में अधिक निर्भरता होती है (100 से अधिक)। एक ही उलटा पैकेज निर्भरता पर लागू होता है: जैसा कि अपेक्षित था, वितरण में कई पैकेजों द्वारा कई पैकेजों का उपयोग किया जाता है, इसलिए इन कुछ पसंदीदा में कमजोरियों का एक उच्च जोखिम है। एक उदाहरण के रूप में, निम्न तालिका SLES, Centos 7, Debian 9, और Ubuntu 18.04 (प्रत्येक बॉक्स पैकेज और व्युत्क्रम निर्भरता की संख्या को इंगित करता है) में व्युत्क्रम निर्भरता की अधिकतम संख्या के साथ 20 संकुल को सूचीबद्ध करता है।


तालिका 3

एक रोचक तथ्य। यद्यपि सभी विश्लेषण किए गए OS x86_64 आर्किटेक्चर के लिए बनाए गए हैं, जबकि अधिकांश पैकेजों में x86_64 और x86 के रूप में परिभाषित आर्किटेक्चर हैं, पैकेज में अक्सर अन्य आर्किटेक्चर के लिए बायनेरी होते हैं, जैसा कि अंजीर में दिखाया गया है। 5।


अंजीर। 5

अगले भाग में, हम विश्लेषण किए गए बायनेरिज़ की विशेषताओं में तल्लीन करेंगे।

बाइनरी सुरक्षा सांख्यिकी

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

$ hardening-check $(which docker) /usr/bin/docker: Position Independent Executable: yes Stack protected: yes Fortify Source functions: no, only unprotected functions found! Read-only relocations: yes Immediate binding: yes 

स्क्रिप्ट पाँच सुरक्षा कार्यों की जाँच करती है :

• स्थिति स्वतंत्र निष्पादन योग्य (PIE): इंगित करता है कि क्या कर्नेल में ASLR सक्षम होने पर यादृच्छिकता प्राप्त करने के लिए प्रोग्राम टेक्स्ट सेक्शन को स्मृति में स्थानांतरित किया जा सकता है।
  
• स्टैक संरक्षित: स्टैक कैनरी को स्टैक टकराव के हमलों से बचाने के लिए शामिल किया गया है या नहीं।
  
• Fortify Source: क्या असुरक्षित फ़ंक्शंस (जैसे कि strcpy) को उनके सुरक्षित समकक्षों द्वारा बदल दिया जाता है, और रनटाइम में चेक किए गए कॉल उनके गैर-सत्यापित समकक्षों (उदाहरण के लिए __mccpy_chk) के बजाय बदल जाते हैं।
  
• केवल-पढ़ने के लिए स्थानांतरण (RELRO): क्या आंदोलन तालिका में प्रविष्टियों को केवल पढ़ने के लिए चिह्नित किया जाता है, यदि वे निष्पादन शुरू होने से पहले काम करते हैं।
  
• तत्काल बाध्यकारी: क्या रनटाइम लिंकर कार्यक्रम शुरू करने से पहले सभी आंदोलनों की अनुमति देता है (यह पूर्ण आरईएलआरओ के बराबर है)।

क्या उपरोक्त तंत्र पर्याप्त हैं? दुर्भाग्य से, नहीं। उपर्युक्त सभी गढ़ों को दरकिनार करने के लिए ज्ञात तरीके हैं, लेकिन जितनी अधिक कड़ी रक्षा होती है, हमलावर के लिए उतना ही अधिक बार। उदाहरण के लिए, RIERO वर्कअराउंड लागू करने के लिए कठिन है अगर PIE और तत्काल बाध्यकारी प्रभाव में हैं। इसी तरह, एक पूर्ण एएसएलआर को एक कार्यशील शोषण बनाने के लिए अतिरिक्त काम की आवश्यकता होती है। हालांकि, परिष्कृत हमलावर ऐसे बचाव को पूरा करने के लिए तैयार हैं: उनकी अनुपस्थिति अनिवार्य रूप से हैकिंग में तेजी लाएगी। इसलिए, यह जरूरी है कि इन उपायों को आवश्यक न्यूनतम माना जाए।

हम यह अध्ययन करना चाहते थे कि प्रश्न में वितरण में कितनी बाइनरी फाइलें इनसे सुरक्षित हैं, साथ ही साथ तीन और तरीके:

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

तो, आगे की हलचल के बिना, संख्याओं पर चलते हैं। टेबल्स 4 और 5 में क्रमशः निष्पादन योग्य फ़ाइलों और पुस्तकालयों के विभिन्न वितरणों के विश्लेषण का एक निचोड़ है।

• जैसा कि आप देख सकते हैं, दुर्लभ अपवादों के साथ, हर जगह एनएक्स संरक्षण लागू किया गया है। विशेष रूप से, Ubuntu और डेबियन वितरण में इसका कम उपयोग CentOS, RHEL और OpenSUSE की तुलना में नोट किया जा सकता है।
  
• स्टैक कैनरी कई स्थानों पर उपलब्ध नहीं हैं, विशेष रूप से पुरानी गुठली के साथ वितरण में। सेंटोस, आरएचईएल, डेबियन और उबंटू के हालिया वितरण में कुछ प्रगति देखी गई है।
  
• डेबियन और उबंटू 18.04 के अपवाद के साथ, अधिकांश वितरणों में खराब पाई समर्थन है।
  
• स्टैक टकराने की सुरक्षा OpenSUSE, Centos 7 और RHEL 7 में खराब रूप से लागू की गई है और बाकी हिस्सों से व्यावहारिक रूप से अनुपस्थित है।
  
• आधुनिक गुठली के साथ सभी वितरणों में कुछ RELRO का समर्थन होता है, उबंटू 18.04 के साथ आगे बढ़ता है, जिसमें डेबियन दूसरे स्थान पर है।

जैसा कि पहले ही उल्लेख किया गया है, इस तालिका में मैट्रिक्स बाइनरी फ़ाइल के सभी संस्करणों पर औसत हैं। यदि आप केवल फाइलों के नवीनतम संस्करणों को देखते हैं, तो संख्याएं भिन्न होंगी (उदाहरण के लिए, पाई के कार्यान्वयन के साथ डेबियन की प्रगति देखें)। इसके अलावा, अधिकांश वितरण आमतौर पर जब आंकड़ों की गणना करते हैं, तो बाइनरी कोड में केवल कुछ कार्यों की सुरक्षा की जांच होती है, और हमारे विश्लेषण में मजबूत कार्यों का सही प्रतिशत इंगित किया गया है। इसलिए, यदि 50 में से 5 कार्य बाइनरी में संरक्षित हैं, तो हम इसे 0.1 की रेटिंग देंगे, जो कि मजबूत कार्यों के 10% से मेल खाती है।


तालिका 4. अंजीर में दिखाए गए निष्पादन योग्य फ़ाइलों के लिए सुरक्षा विशेषताएं। 3 (निष्पादन योग्य फ़ाइलों की कुल संख्या के प्रतिशत के रूप में संबंधित कार्यों का कार्यान्वयन)


तालिका 5. अंजीर में दिखाए गए पुस्तकालयों के लिए सुरक्षा विशेषताएं। 3 (पुस्तकालयों की कुल संख्या के प्रतिशत के रूप में संबंधित कार्यों का कार्यान्वयन)

तो क्या प्रगति है? निश्चित रूप से है: इसे व्यक्तिगत वितरण (उदाहरण के लिए, डेबियन ) के आंकड़ों के साथ-साथ ऊपर की तालिकाओं से भी देखा जा सकता है। अंजीर में एक उदाहरण के रूप में। चित्र 6 में लगातार तीन उबंटू LTS 5 वितरणों में रक्षा तंत्र के कार्यान्वयन को दिखाया गया है (हमने स्टैक टक्कर सुरक्षा आँकड़ों को छोड़ दिया है)। हम देखते हैं कि संस्करण से लेकर संस्करण तक अधिक से अधिक फाइलें स्टैक्ड कैनरीज़ का समर्थन करती हैं, और क्रमिक रूप से अधिक से अधिक बाइनरी फाइलें पूरी RELRO सुरक्षा के साथ आती हैं।


अंजीर। 6

दुर्भाग्य से, विभिन्न वितरणों में निष्पादन योग्य फ़ाइलों की संख्या में अभी भी उपरोक्त सुरक्षा नहीं है। उदाहरण के लिए, उबंटू 18.04 को देखते हुए, आप नेगट्टी बाइनरी (गेटी रिप्लेसमेंट), साथ ही साथ mksh और lksh गोले, पिकोलिस्प इंटरप्रेटर, एनवीडिया-क्यूडा-टूलकिट पैकेज (मशीन सीखने की रूपरेखा जैसे GPU-त्वरित अनुप्रयोगों के लिए एक लोकप्रिय पैकेज) और klibc देख सकते हैं -utils। इसी तरह, मैंडोस-क्लाइंट बाइनरी (एक प्रशासनिक उपकरण जो आपको एन्क्रिप्टेड फ़ाइल सिस्टम के साथ मशीनों को स्वचालित रूप से पुनरारंभ करने की अनुमति देता है), साथ ही साथ rsh-redone-client (पुन: लागू करने वाले rsh और rlogin) को NX सुरक्षा के बिना वितरित किया जाता है, हालांकि वे SUID अधिकार :( इसके अलावा में हैं।) कई suid binaries में बुनियादी सुरक्षा नहीं होती है, जैसे कि स्टैक कैनरी (उदाहरण के लिए, Xorg.wrap बाइनरी XX पैकेज से)।

सारांश और समापन टिप्पणी

इस लेख में, हमने आधुनिक लिनक्स वितरण की कई सुरक्षा विशेषताओं पर प्रकाश डाला। विश्लेषण से पता चला कि नवीनतम उबंटू एलटीएस वितरण (18.04) ने अपेक्षाकृत नए कर्नेल के साथ वितरण के बीच सबसे मजबूत ओएस और आवेदन स्तर के संरक्षण को लागू किया, जैसे कि उबंटू 14.04, 12.04, और डेबियन 9। हालांकि, हमारे किट में चर्चा की CentOS, RHEL और OpenSUSE वितरण। डिफ़ॉल्ट रूप से, पैकेजों का एक सघन सेट जारी किया जाता है, और नवीनतम संस्करणों (CentOS और RHEL) में डेबियन (डेबियन और उबंटू) पर आधारित प्रतियोगियों की तुलना में स्टैक टकराव की सुरक्षा का उच्च प्रतिशत होता है। CentOS और RedHat संस्करणों की तुलना में, हम स्टैक कैनरी और RELRO के 6 से 7 के संस्करण के कार्यान्वयन में बड़े सुधारों को देखते हैं, लेकिन औसतन CentOS में RHEL की तुलना में अधिक विशेषताएं हैं। सामान्य तौर पर, सभी वितरणों को PIE सुरक्षा पर विशेष ध्यान देना चाहिए, जो कि डेबियन 9 और उबंटू 18.04 के अपवाद के साथ, हमारे डेटासेट से 10% से कम बाइनरी फाइलों में लागू किया गया है।

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