TL; ड। यस लेखमा, हामी पाँच लोकप्रिय लिनक्स वितरणहरूमा बक्स बाहिर काम गर्ने कडा योजनाहरू अन्वेषण गर्छौं। प्रत्येकको लागि, हामीले पूर्वनिर्धारित कर्नेल कन्फिगरेसन लियौं, सबै प्याकेजहरू लोड गर्यौं, र संलग्न बाइनरीहरूमा सुरक्षा योजनाहरूको विश्लेषण गर्यौं। विचार गरिएका वितरणहरू OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 र 7, साथै Ubuntu 14.04, 12.04 र 18.04 LTS हुन्।

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

समीक्षाले देखाएको छ कि सबैभन्दा ठूलो संख्यामा सुरक्षा विधिहरू Ubuntu 18.04 मा OS र अनुप्रयोग स्तरहरूमा लागू गरिएको छ, त्यसपछि Debian 9। अर्कोतर्फ, OpenSUSE 12.4, CentOS 7 र RHEL 7 ले पनि आधारभूत सुरक्षा योजनाहरू लागू गर्दछ, र स्ट्याक टक्कर सुरक्षा। पूर्वनिर्धारित प्याकेजहरूको धेरै सघन सेटको साथ अझ व्यापक रूपमा प्रयोग गरिन्छ।

परिचय

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

यो जहाँ सुरक्षा वा कडा कार्यक्रमहरूको विधिहरू खेलमा आउँछन्। हामी केहि प्रकारका त्रुटिहरूलाई रोक्न सक्दैनौं, तर हामी आक्रमणकारीको जीवनलाई अझ कठिन बनाउन सक्छौं र आंशिक रूपमा रोक्न वा रोकथाम गरेर समस्या समाधान गर्न सक्छौं। शोषण यी त्रुटिहरू। यस्तो सुरक्षा सबै आधुनिक अपरेटिङ सिस्टमहरूमा प्रयोग गरिन्छ, तर विधिहरू जटिलता, दक्षता र प्रदर्शनमा धेरै भिन्न हुन्छन्: स्ट्याक क्यानरीहरू र ASLR पूर्ण सुरक्षा गर्न CFI и ROP। यस लेखमा, हामी पूर्वनिर्धारित कन्फिगरेसनमा सबैभन्दा लोकप्रिय लिनक्स वितरणहरूमा कुन सुरक्षा विधिहरू प्रयोग गरिन्छ भनेर हेर्नेछौं, र प्रत्येक वितरणको प्याकेज व्यवस्थापन प्रणालीहरू मार्फत वितरित बाइनरीहरूको गुणहरू पनि जाँच्नेछौं।

CVE र सुरक्षा

हामीले "वर्षको सबैभन्दा कमजोर अनुप्रयोगहरू" वा "सबैभन्दा कमजोर अपरेटिङ सिस्टमहरू" जस्ता शीर्षकहरू भएका लेखहरू देखेका छौं। सामान्यतया तिनीहरूले कमजोरीहरूको बारेमा रेकर्डहरूको कुल संख्यामा तथ्याङ्कहरू प्रदान गर्छन् CVE (सामान्य जोखिम र एक्सपोजर), बाट प्राप्त राष्ट्रिय जोखिम डाटाबेस (NVD) देखि NIST र अन्य स्रोतहरू। पछि, यी एप्लिकेसनहरू वा OS लाई CVE को संख्याद्वारा क्रमबद्ध गरिन्छ। दुर्भाग्यवश, CVEs समस्याहरू ट्र्याक गर्न र विक्रेताहरू र प्रयोगकर्ताहरूलाई सूचित गर्नका लागि धेरै उपयोगी हुँदा, तिनीहरूले सफ्टवेयरको वास्तविक सुरक्षाको बारेमा थोरै भनेका छन्।

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

Рис। १

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

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

Рис। १

कार्यहरू

यस लेखमा हामी निम्न प्रश्नहरूको जवाफ दिन चाहन्छौं:

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

वितरण को चयन

यो बाहिर जान्छ कि वितरण स्थापनाहरूमा सही तथ्याङ्कहरू फेला पार्न गाह्रो छ, किनकि धेरै जसो केसहरूमा डाउनलोडहरूको संख्याले वास्तविक स्थापनाहरूको संख्यालाई संकेत गर्दैन। यद्यपि, युनिक्स भेरियन्टहरूले सर्भर प्रणालीहरूको बहुमत बनाउँछ (वेब ​​सर्भरहरूमा 69,2%, द्वारा तथ्या .्क W3techs र अन्य स्रोतहरू), र तिनीहरूको साझेदारी निरन्तर बढ्दै गएको छ। यसैले, हाम्रो अनुसन्धानको लागि हामीले प्लेटफर्ममा बक्स बाहिर उपलब्ध वितरणहरूमा ध्यान केन्द्रित गर्यौं गुगल क्लाउड। विशेष गरी, हामीले निम्न OS चयन गर्यौं:

वितरण/संस्करण
कर्नेल
निर्माण गर्नुहोस्

OpenSUSE १
४.१२.१४-९५.३-पूर्वनिर्धारित
#1 SMP बुध डिसेम्बर 5 06:00:48 UTC 2018 (63a8d29)

डेबियन ९ (स्ट्रेच)
4.9.0-8-amd64
#1 SMP डेबियन 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP मङ्गल 15 जनवरी 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP शुक्र फेब्रुअरी 1 14:54:57 UTC 2019

Red Hat Enterprise Linux सर्भर 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP बुध नोभेम्बर 21 15:08:21 EST 2018

Red Hat Enterprise Linux सर्भर 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP बिहीबार नोभेम्बर 15 17:36:42 UTC 2018

Ubuntu 14.04 (विश्वसनीय Tahr)
४.४.०–१४०-सामान्य

#166~14.04.1-Ubuntu SMP शनिवार नोभेम्बर 17 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP शुक्र डिसेम्बर 7 09:59:47 UTC 2018

Ubuntu 18.04 (बायोनिक बीभर)
4.15.0–1026-gcp
#27-Ubuntu SMP बिहीबार डिसेम्बर 6 18:27:01 UTC 2018

तालिका 1

Анализ

पूर्वनिर्धारित कर्नेल कन्फिगरेसन, साथै प्रत्येक वितरणको प्याकेज प्रबन्धक मार्फत उपलब्ध प्याकेजहरूको गुणहरू बाकस बाहिर अध्ययन गरौं। यसैले, हामी प्रत्येक वितरणको पूर्वनिर्धारित मिररहरूबाट प्याकेजहरू मात्र विचार गर्छौं, अस्थिर भण्डारहरू (जस्तै डेबियन 'परीक्षण' मिररहरू) र तेस्रो-पक्ष प्याकेजहरू (जस्तै मानक मिररहरूबाट Nvidia प्याकेजहरू) लाई बेवास्ता गर्दै। थप रूपमा, हामी अनुकूलन कर्नेल संकलन वा सुरक्षा-कठोर कन्फिगरेसनहरू विचार गर्दैनौं।

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

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

सामान्यतया, नयाँ कर्नेलहरूमा बक्स बाहिर कडा सेटिङहरू छन्। उदाहरणका लागि, 6.10 कर्नेलमा CentOS 6.10 र RHEL 2.6.32 मा नयाँ कर्नेलहरूमा लागू गरिएका धेरैजसो महत्वपूर्ण सुविधाहरूको अभाव छ। SMAP, कडा RWX अनुमतिहरू, ठेगाना अनियमितता वा copy2usr सुरक्षा। यो ध्यान दिनुपर्छ कि तालिकामा धेरै कन्फिगरेसन विकल्पहरू कर्नेलको पुरानो संस्करणहरूमा उपलब्ध छैनन् र वास्तविकतामा लागू हुँदैनन् - यो अझै पनि उपयुक्त सुरक्षाको अभावको रूपमा तालिकामा संकेत गरिएको छ। त्यसै गरी, यदि दिइएको संस्करणमा कन्फिगरेसन विकल्प अवस्थित छैन, र सुरक्षालाई त्यो विकल्प असक्षम पार्न आवश्यक छ भने, यो एक उचित कन्फिगरेसन मानिन्छ।

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

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

आवेदन विश्लेषण

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

वितरणहरू

कुलमा, हामीले सबै वितरणका लागि 361 प्याकेजहरू डाउनलोड गर्यौं, पूर्वनिर्धारित मिररहरूबाट मात्र प्याकेजहरू निकाल्दै। हामीले स्रोतहरू, फन्टहरू, आदि जस्ता ELF कार्यान्वयनयोग्यहरू बिना प्याकेजहरूलाई बेवास्ता गर्यौं। फिल्टर गरिसकेपछि, कुल 556 बाइनरीहरू समावेश गरी 129 प्याकेजहरू बाँकी छन्। वितरणहरूमा प्याकेज र फाइलहरूको वितरण चित्रमा देखाइएको छ। ३.

Рис। १

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

Рис। १

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

तालिका 3

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

Рис। १

अर्को खण्डमा, हामी विश्लेषण गरिएको बाइनरीहरूका विशेषताहरूको खोजी गर्नेछौं।

बाइनरी फाइल सुरक्षा तथ्याङ्क

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

$ 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 कर्नेलमा सक्षम गरिएको छ भने अनियमितता प्राप्त गर्नको लागि कार्यक्रमको पाठ खण्ड मेमोरीमा सार्न सकिन्छ कि भनेर संकेत गर्दछ।
• स्ट्याक सुरक्षित: स्ट्याक टक्कर आक्रमणहरू विरुद्ध सुरक्षा गर्न स्ट्याक क्यानरीहरू सक्षम छन्।
• स्रोत बलियो बनाउनुहोस्: असुरक्षित प्रकार्यहरू (उदाहरणका लागि, strcpy) तिनीहरूको अधिक सुरक्षित समकक्षहरूसँग प्रतिस्थापन गरिएको छ, र रनटाइममा जाँच गरिएका कलहरू तिनीहरूको अनचेक समकक्षहरू (उदाहरणका लागि, __memcpy_chk को सट्टा memcpy) द्वारा प्रतिस्थापित गरिन्छ।
• रिड-ओन्ली रिलोकेसन्स (RELRO): कार्यान्वयन सुरु हुनु अघि ट्रिगर गरिएको खण्डमा स्थानान्तरण तालिका प्रविष्टिहरूलाई पढ्न मात्र चिन्ह लगाइन्छ।
• तत्काल बाइन्डिङ: कार्यक्रम कार्यान्वयन सुरु हुनु अघि रनटाइम लिङ्करले सबै चालहरूलाई अनुमति दिन्छ (यो पूर्ण RELRO बराबर हो)।

के माथिका संयन्त्रहरू पर्याप्त छन्? दुर्भाग्यवश छैन। त्यहाँ माथिका सबै प्रतिरक्षाहरू बाइपास गर्ने तरिकाहरू ज्ञात छन्, तर रक्षा जति कडा हुन्छ, आक्रमणकारीको लागि उच्च बार। उदाहरण को लागी, RELRO बाइपास विधिहरू PIE र तत्काल बाइन्डिङ प्रभावकारी भएमा लागू गर्न अझ गाह्रो हुन्छ। त्यस्तै गरी, पूर्ण ASLR लाई कार्य शोषण सिर्जना गर्न थप काम चाहिन्छ। यद्यपि, परिष्कृत आक्रमणकारीहरू पहिले नै त्यस्ता सुरक्षाहरू पूरा गर्न तयार छन्: तिनीहरूको अनुपस्थितिले अनिवार्य रूपमा ह्याकलाई गति दिनेछ। तसर्थ यी उपायहरू आवश्यक मान्न आवश्यक छ न्यूनतम.

हामी अध्ययन गर्न चाहन्थ्यौं कि कति बाइनरी फाइलहरू प्रश्नमा वितरणमा यी र तीन अन्य विधिहरूद्वारा सुरक्षित छन्:

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

त्यसोभए, थप विज्ञापन बिना, नम्बरहरूमा तल जाऔं। तालिका 4 र 5 मा क्रमशः कार्यान्वयनयोग्य फाइलहरू र विभिन्न वितरणहरूको पुस्तकालयहरूको विश्लेषणको सारांश समावेश छ।

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

पहिले नै उल्लेख गरिएझैं, यस तालिकामा भएका मेट्रिकहरू बाइनरी फाइलका सबै संस्करणहरूको लागि औसत हुन्। यदि तपाईंले फाइलहरूको नवीनतम संस्करणहरू मात्र हेर्नुभयो भने, संख्याहरू फरक हुनेछन् (उदाहरणका लागि, हेर्नुहोस् PIE कार्यान्वयनको साथ डेबियन प्रगति)। यसबाहेक, धेरै वितरणहरूले सामान्यतया बाइनरीमा केही प्रकार्यहरूको सुरक्षा मात्र परीक्षण गर्दछ जब तथ्याङ्कहरू गणना गरिन्छ, तर हाम्रो विश्लेषणले कडा भएका कार्यहरूको वास्तविक प्रतिशत देखाउँछ। त्यसकारण, यदि 5 मध्ये 50 प्रकार्यहरू बाइनरीमा सुरक्षित छन् भने, हामी यसलाई 0,1 को स्कोर दिनेछौं, जुन सुदृढीकरण गरिएका प्रकार्यहरूको 10% सँग मेल खान्छ।

तालिका ४. चित्रमा देखाइएको कार्यान्वयनयोग्य फाइलहरूको सुरक्षा विशेषताहरू। 4 (कार्यान्वयनयोग्य फाइलहरूको कुल संख्याको प्रतिशतको रूपमा प्रासंगिक कार्यहरूको कार्यान्वयन)

तालिका ५. चित्रमा देखाइएको पुस्तकालयहरूको सुरक्षा विशेषताहरू। ३ (पुस्तकालयहरूको कुल संख्याको प्रतिशतको रूपमा सान्दर्भिक कार्यहरूको कार्यान्वयन)

त्यसोभए प्रगति छ? त्यहाँ निश्चित रूपमा छ: यो व्यक्तिगत वितरणको तथ्याङ्कबाट देख्न सकिन्छ (उदाहरणका लागि, Debian), साथै माथिको तालिकाबाट। चित्रमा उदाहरणको रूपमा। चित्र 6 ले Ubuntu LTS 5 (हामीले स्ट्याक टक्कर सुरक्षा तथ्याङ्कहरू हटाएका छौं) को लगातार तीनवटा वितरणहरूमा सुरक्षा संयन्त्रहरूको कार्यान्वयन देखाउँछ। हामीले नोटिस गर्छौं कि संस्करण देखि संस्करणमा अधिक र धेरै फाइलहरूले स्ट्याक क्यानरीहरूलाई समर्थन गर्दछ, र थप र अधिक बाइनरीहरू पूर्ण RELRO सुरक्षाको साथ पठाइन्छ।

Рис। १

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

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

यस लेखमा, हामीले आधुनिक लिनक्स वितरणका धेरै सुरक्षा सुविधाहरू हाइलाइट गरेका छौं। विश्लेषणले देखाएको छ कि पछिल्लो Ubuntu LTS वितरण (18.04) ले औसतमा, Ubuntu 14.04, 12.04 र Debian 9 जस्ता नयाँ कर्नेलहरू भएका वितरणहरू बीच सबैभन्दा बलियो OS र अनुप्रयोग स्तर सुरक्षा लागू गर्दछ। यद्यपि, जाँच गरिएको वितरण CentOS, RHEL र हाम्रो सेटमा OpenSUSE पूर्वनिर्धारित रूपमा तिनीहरूले प्याकेजहरूको सघन सेट उत्पादन गर्छन्, र नवीनतम संस्करणहरूमा (CentOS र RHEL) तिनीहरूसँग डेबियन-आधारित प्रतिस्पर्धीहरू (Debian र Ubuntu) को तुलनामा स्ट्याक टक्कर सुरक्षाको उच्च प्रतिशत छ। CentOS र RedHat संस्करणहरू तुलना गर्दै, हामीले संस्करण 6 देखि 7 सम्म स्ट्याक क्यानरीहरू र RELRO को कार्यान्वयनमा ठूलो सुधारहरू देख्छौं, तर औसतमा CentOS मा RHEL भन्दा बढि सुविधाहरू लागू गरिएको छ। सामान्यतया, सबै वितरणहरूले PIE सुरक्षामा विशेष ध्यान दिनुपर्छ, जुन, Debian 9 र Ubuntu 18.04 को अपवाद बाहेक, हाम्रो डेटासेटमा 10% भन्दा कम बाइनरीहरूमा लागू गरिएको छ।

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

स्रोत: www.habr.com