कैसे लिनक्स लिनक्स कर्नेल सुरक्षा में सुधार करता है

STACKLEAK एक लिनक्स कर्नेल सुरक्षा सुविधा है जिसे मूल रूप से Grsecurity / PaX के रचनाकारों द्वारा विकसित किया गया है। मैंने STACKLEAK को आधिकारिक वेनिला कर्नेल (लिनक्स कर्नेल मेनलाइन) में लाने का फैसला किया। यह लेख आंतरिक संरचना, इस सुरक्षा समारोह के गुणों और इसके मुख्य मार्ग में बहुत लंबे पथ के बारे में बात करेगा।





STACKLEAK लिनक्स कर्नेल में कमजोरियों के कई वर्गों से बचाता है, अर्थात्:

• हमलावर के लिए उपयोगी जानकारी को कम कर देता है, जिसे परमाणु स्टैक से उपयोगकर्ता स्थान पर लीक किया जा सकता है;
• कर्नेल स्टैक में अनियंत्रित चर पर कुछ हमलों को रोकता है;
• डायनेमिक स्टैक ओवरफ़्लो डिटेक्शन टूल प्रदान करता है।

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

STACKLEAK ग्रामसुरक्षा / PaX पैच में PAX_MEMORY_STACKLEAK के रूप में मौजूद है। हालांकि, अप्रैल 2017 से मुफ्त में वितरित किया जाना बंद हो गया है। इसलिए, वेनिला कर्नेल में STACKLEAK का दिखना लिनक्स उपयोगकर्ताओं के लिए मूल्यवान होगा, जिसमें सूचना सुरक्षा की आवश्यकताएं होती हैं।

कार्य क्रम:

• ग्रेस्केलिटी / PaX पैच से STACKLEAK का चयन करें,
• कोड का ध्यानपूर्वक अध्ययन करें और एक पैच बनाएं,
• एलकेएमएल को भेजें, प्रतिक्रिया प्राप्त करें, सुधार करें, मेनलाइन में स्वीकार किए जाने से पहले फिर से दोहराएं।

लेखन के समय (25 सितंबर, 2018), पैच की एक श्रृंखला का संस्करण 15 भेजा गया था। इसमें x86_64 और x86_32 के लिए एक वास्तुशिल्प रूप से स्वतंत्र भाग और कोड है। Red64 के लौरा एबॉट द्वारा विकसित arm64 के लिए STACKLEAK समर्थन, पहले से ही वेनिला कर्नेल 4.19 में लाने में कामयाब रहा है।

STACKLEAK: सुरक्षा सुविधाएँ

कर्नेल स्टैक में अवशिष्ट जानकारी समाशोधन

यह उपाय उपयोगी जानकारी को कम करता है जो परमाणु स्टैक से उपयोगकर्ता स्थान तक कुछ लीक का उत्पादन कर सकता है।

कर्नेल स्टैक से सूचना रिसाव का एक उदाहरण चित्र 1 में प्रस्तुत किया गया है।



स्कीम 1।

हालांकि, इस प्रकार के लीक बेकार हो जाते हैं यदि, सिस्टम कॉल के अंत में, कर्नेल स्टैक का उपयोग किया गया हिस्सा एक निश्चित मूल्य (चित्रा 2) से भरा होता है।



योजना २।

परिणामस्वरूप, STACKLEAK कर्नेल स्टैक में अनइंस्टॉल किए गए चर पर कुछ हमलों को रोकता है। ऐसी कमजोरियों के उदाहरण: CVE-2017-17712, CVE-2010-2963। हम Kees कुक के एक लेख में CVE-2010-2963 भेद्यता के लिए शोषण पद्धति का वर्णन पा सकते हैं।

कर्नेल स्टैक में एक uninitialized चर पर हमले का सार चित्र 3 में दिखाया गया है।



स्कीम 3।

STACKLEAK इस प्रकार के हमलों को रोकता है, क्योंकि सिस्टम कॉल के अंत में परमाणु स्टैक को पॉप्युलेट करने वाले मान वर्चुअल एड्रेस स्पेस (चित्र 4) में अप्रयुक्त क्षेत्र को इंगित करता है।



स्कीम 4।

एक महत्वपूर्ण सीमा यह है कि STACKLEAK एकल सिस्टम कॉल में किए गए समान हमलों से रक्षा नहीं करता है।

इन-कर्नेल कोर स्टैक ओवरफ़्लो डिटेक्शन

वेनिला कर्नेल (लिनक्स कर्नेल मेनलाइन) में STACKLEAK केवल CONFIG_THREAD_INFO_IN_TASK और CONFIG_VMAP_VACK के साथ संयोजन के रूप में कर्नेल स्टैक गहराई अतिप्रवाह के खिलाफ प्रभावी है। ये दोनों उपाय एंडी लुटोमिरस्की द्वारा लागू किए गए हैं।

इस प्रकार की भेद्यता का फायदा उठाने का सबसे सरल संस्करण चित्र 5 में दिखाया गया है।



स्कीम 5।

परमाणु स्टैक के तल पर थ्रेड_इनफो संरचना में कुछ क्षेत्रों को ओवरराइट करने से प्रक्रिया के विशेषाधिकार बढ़ सकते हैं। हालाँकि, जब CONFIG_THREAD_INFO_IN_TASK विकल्प सक्षम होता है, तो इस संरचना को परमाणु स्टैक से हटा दिया जाता है, जो भेद्यता के दोहन की वर्णित विधि को समाप्त कर देता है।

इस हमले का एक और अधिक उन्नत संस्करण स्टैक बॉर्डर से बाहर जाकर पड़ोसी मेमोरी क्षेत्र में डेटा को अधिलेखित करना है। इस दृष्टिकोण पर अधिक:

• जॉन ओबेरहाइड की " द स्टैक इज बैक " की प्रस्तुति में,
• Jann Horn द्वारा " लिनक्स कर्नेल में पुनरावृत्ति का खुलासा " लेख में ।

इस प्रकार का हमला चित्र 6 में परिलक्षित होता है।



स्कीम 6।

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



स्कीम 7।

अंत में, स्टैक को गहराई से ओवरफ्लो करने का सबसे दिलचस्प विकल्प स्टैक क्लैश जैसा हमला है। इस विचार को 2005 में गेल डेल्लाउ ने वापस रखा ।

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



स्कीम 8।

STACKLEAK और स्टैक क्लैश के बारे में अधिक जानकारी के लिए, gsecurity ब्लॉग देखें ।

परमाणु स्टैक में स्टैक क्लैश से कैसे बचा जाए? एलोका () के लिए प्रत्येक कॉल से पहले, स्टैक ओवरफ्लो के लिए गहराई से एक चेक किया जाता है। यहाँ पैच श्रृंखला के संस्करण 14 से संबंधित कोड है:

void __used stackleak_check_alloca(unsigned long size) { unsigned long sp = (unsigned long)&sp; struct stack_info stack_info = {0}; unsigned long visit_mask = 0; unsigned long stack_left; BUG_ON(get_stack_info(&sp, current, &stack_info, &visit_mask)); stack_left = sp - (unsigned long)stack_info.begin; if (size >= stack_left) { /* * Kernel stack depth overflow is detected, let's report that. * If CONFIG_VMAP_STACK is enabled, we can safely use BUG(). * If CONFIG_VMAP_STACK is disabled, BUG() handling can corrupt * the neighbour memory. CONFIG_SCHED_STACK_END_CHECK calls * panic() in a similar situation, so let's do the same if that * option is on. Otherwise just use BUG() and hope for the best. */ #if !defined(CONFIG_VMAP_STACK) && defined(CONFIG_SCHED_STACK_END_CHECK) panic("alloca() over the kernel stack boundary\n"); #else BUG(); #endif } } 

हालाँकि, इस कार्यक्षमता को संस्करण 15 से बाहर रखा गया था। लिनक्स कर्नेल सुरक्षा पैच में BUG_ON () का उपयोग करने पर मुख्य रूप से लिनुस टोरवाल्ड्स के विवादास्पद प्रतिबंध के कारण यह था।

इसके अलावा, पैच श्रृंखला के 9 वें संस्करण ने एक चर्चा का नेतृत्व किया, जिसके परिणामस्वरूप मेनलाइन कर्नेल से सभी चर सरणियों को समाप्त करने का निर्णय लिया गया। लगभग 15 डेवलपर्स इस काम में शामिल थे, और यह जल्द ही समाप्त हो जाएगा।

STACKLEAK प्रदर्शन प्रभाव

मैं x86_64 पर प्रदर्शन परीक्षण के परिणाम देता हूं। उपकरण: इंटेल कोर i7-4770, 16 जीबी रैम।

टेस्ट # 1, आकर्षक: एक सिंगल कोर पर लिनक्स कर्नेल का निर्माण

  # time make   4.18: real 12m14.124s user 11m17.565s sys 1m6.943s   4.18+stackleak: real 12m20.335s (+0.85%) user 11m23.283s sys 1m8.221s 

टेस्ट नंबर 2, अनाकर्षक:

  # hackbench -s 4096 -l 2000 -g 15 -f 25 -P    4.18: 9.08     4.18+stackleak: 9.47  (+4.3%) 

इसलिए, सिस्टम प्रदर्शन पर STACKLEAK का प्रभाव लोड के प्रकार पर निर्भर करता है। विशेष रूप से, बड़ी संख्या में शॉर्ट सिस्टम कॉल ओवरहेड बढ़ाते हैं। इस प्रकार उत्पादन से पहले नियोजित भार के लिए STACKLEAK प्रदर्शन का मूल्यांकन किया जाना चाहिए।

आंतरिक उपकरण STACKLEAK

STACKLEAK में शामिल हैं:

• कोड जो सिस्टम कॉल के अंत में कर्नेल स्टैक को साफ़ करता है (मूल रूप से कोडांतरक में लिखा गया है),
• कर्नेल कोड के इंस्ट्रुमेंटल संकलन के लिए जीसीसी प्लगइन।

कर्नेल स्टैक को साफ़ करना स्टैकलेक_रेज़ () फ़ंक्शन में किया जाता है। यह फ़ंक्शन सिस्टम कॉल के बाद उपयोगकर्ता स्थान पर लौटने से पहले पूरा करता है। STACKLEAK_POISON (-0xBEEF) थ्रेड स्टैक के उपयोग किए गए भाग को लिखा जाता है। सबसे कम_स्टैक चर, जो लगातार स्टैकलैक_ट्रैक_स्टैक () में अपडेट किया जाता है, क्लीनअप स्टार्ट पॉइंट की ओर इशारा करता है।

9 और 10 योजनाओं में स्टैकलैक_एरेज़ () के चरण प्रतिबिंबित होते हैं।



स्कीम 9।



स्कीम 10।

इस प्रकार stackleak_erase () परमाणु स्टैक के केवल उपयोग किए गए हिस्से को साफ करता है। यही वजह है कि STACKLEAK इतना तेज है। और यदि आप प्रत्येक सिस्टम कॉल के अंत में x86_64 पर कर्नेल स्टैक के सभी 16 kB को स्पष्ट करते हैं, तो हैकबेंच 40% का प्रदर्शन ड्रॉप दिखाता है।

संकलन चरण में कर्नेल कोड का इंस्टॉलेशन STACKLEAK GCC प्लगइन में किया जाता है।

GCC प्लगइन्स GCC कंपाइलर के लिए प्रोजेक्ट विशिष्ट डाउनलोड करने योग्य मॉड्यूल हैं। वे जीसीसी पास प्रबंधक के साथ नए पास पंजीकृत करते हैं, इन पासों के लिए कॉलबैक प्रदान करते हैं।

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

जैसा कि पहले ही उल्लेख किया गया है, पैच श्रृंखला के संस्करण 15 में, stackleak_check_alloca () के लिए कॉल की प्रविष्टि को GCC प्लगइन से बाहर रखा गया था।

लिनक्स कर्नेल मेनलाइन में पथ

मेनलाइन में STACKLEAK पथ बहुत लंबा और कठिन है (चित्र 11)।



स्कीम 11. लिनक्स कर्नेल मेनलाइन में STACKLEAK के कार्यान्वयन पर प्रगति।

अप्रैल 2017 में, व्याकरण के रचनाकारों ने समुदाय के लिए अपने पैच बंद कर दिए, उन्हें केवल व्यावसायिक आधार पर वितरित करना शुरू कर दिया। मई 2017 में, मैंने STACKLEAK को वेनिला कोर में पेश करने का काम करने का फैसला किया। इस प्रकार एक वर्ष से अधिक की यात्रा शुरू हुई। कंपनी पॉजिटिव टेक्नोलॉजीज, जिसमें मैं काम करता हूं, मुझे अपने कुछ कार्य समय के लिए इस कार्य से निपटने का अवसर प्रदान करता है। लेकिन मूल रूप से, मैं इस पर "मुक्त" समय बिताता हूं।

पिछले मई से, मेरी पैच श्रृंखला को कई समीक्षाओं से गुजरना पड़ा है, महत्वपूर्ण बदलाव आए हैं, लिनुस टोरवाल्ड्स द्वारा दो बार आलोचना की गई है। मैं इस पूरी बात को कई बार छोड़ना चाहता था। लेकिन एक निश्चित समय पर अंत तक पहुंचने की दृढ़ इच्छा थी। लेखन के समय (25 सितंबर, 2018), पैच श्रृंखला का 15 वां संस्करण लिनक्स-अगली शाखा में है, लिनुस की सभी उल्लिखित आवश्यकताओं को पूरा करता है और 4.20 / 5.0 कर्नेल के मर्ज-विंडो के लिए तैयार है।

एक महीने पहले, मैंने लिनक्स सिक्योरिटी समिट पर इस काम के बारे में बात की थी। मैं स्लाइड और वीडियो के लिंक प्रदान करता हूं:

निष्कर्ष

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

पुनश्च

STACKLEAK को अंततः Linux 4.20 कर्नेल द्वारा अपनाया गया:
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d6bb6adb714b133db92ccd4bfc9c20f75f71f3f

समर्थित आर्किटेक्चर x86_64, x86_32 और arm64 हैं।

इसके अलावा, लिनक्स कर्नेल कोड से चर-लंबाई सरणियों को खत्म करने के लिए काम पूरा हो गया है। Gcc संकलक चेतावनी "-Wvla" कर्नेल संस्करण में शामिल है 4.20: lkml.org/lkml/2018/10/28/189