sofianehamlaoui/cve-2022-0492-checkerएक स्क्रिप्ट यह जाँचने के लिए कि क्या कोई कंटेनर वातावरण CVE-2022-0492 के माध्यम से कंटेनर एस्केप के लिए असुरक्षित है।
एक स्क्रिप्ट जो यह जाँचती है कि क्या कंटेनर वातावरण CVE-2022-0492 के माध्यम से कंटेनर एस्केप के लिए संवेदनशील है।
4 फरवरी को, Linux ने कर्नेल में एक नई विशेषाधिकार वृद्धि भेद्यता CVE-2022-0492 की घोषणा की।
CVE-2022-0492 कंट्रोल ग्रुप्स (cgroups) में एक तार्किक बग है, जो कंटेनरों का मूलभूत निर्माण खंड होने वाली Linux सुविधा है। यह मुद्दा हाल के दिनों में खोजी गई सबसे सरल Linux विशेषाधिकार वृद्धि में से एक के रूप में सामने आता है: Linux कर्नेल ने गलती से एक विशेषाधिकार प्राप्त ऑपरेशन को अन-विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए उजागर कर दिया।
सौभाग्य से, अधिकांश कंटेनर वातावरणों में डिफ़ॉल्ट सुरक्षा कठोरीकरण कंटेनर एस्केप को रोकने के लिए पर्याप्त हैं। AppArmor या SELinux के साथ चलने वाले कंटेनर सुरक्षित हैं। यह कहने के बाद, यदि आप बेस्ट प्रैक्टिस कठोरीकरण के बिना, या अतिरिक्त विशेषाधिकारों के साथ कंटेनर चलाते हैं, तो आप जोखिम में हो सकते हैं। "क्या मैं प्रभावित हूँ?" अनुभाग संवेदनशील कंटेनर कॉन्फ़िगरेशन सूचीबद्ध करता है और यह परीक्षण करने के निर्देश प्रदान करता है कि क्या कंटेनर वातावरण संवेदनशील है।
कंटेनरों के अलावा, यह भेद्यता बिना किसी क्षमता वाले रूट होस्ट प्रोसेस, या CAP_DAC_OVERRIDE क्षमता वाले नॉन-रूट होस्ट प्रोसेस को भी विशेषाधिकार बढ़ाने और सभी क्षमताओं को प्राप्त करने की अनुमति दे सकती है। यह हमलावरों को कुछ सेवाओं द्वारा उपयोग किए जाने वाले एक कठोरीकरण उपाय को दरकिनार करने की अनुमति दे सकता है, जो समझौता होने पर प्रभाव को सीमित करने के प्रयास में क्षमताओं को हटा देती हैं।
CVE-2022-0492 अब हाल के महीनों में तीसरी कर्नेल भेद्यता है जो दुर्भावनापूर्ण कंटेनरों को एस्केप करने की अनुमति देती है। तीनों भेद्यताओं में, कंटेनरों को Seccomp और AppArmor या SELinux में से किसी एक के साथ सुरक्षित करना कंटेनर एस्केप को रोकने के लिए पर्याप्त था।
cgroupfs को माउंट करने के लिए वर्तमान cgroup namespace को होस्ट करने वाले user namespace में CAP_SYS_ADMIN क्षमता की आवश्यकता होती है। डिफ़ॉल्ट रूप से, कंटेनर CAP_SYS_ADMIM के बिना चलते हैं, और इस प्रकार प्रारंभिक user namespace में cgroupfs को माउंट नहीं कर सकते। लेकिन unshare() syscall के माध्यम से, कंटेनर नए user और cgroup namespaces बना सकते हैं जहाँ उनके पास CAP_SYS_ADMIN क्षमता होती है और वे cgroupfs को माउंट कर सकते हैं।
चित्र 1 - एक कंटेनर एक नया user namespace बना रहा है जहाँ उसके पास CAP_SYS_ADMIN क्षमता होगी।
हर कंटेनर एक नया user namespace नहीं बना सकता – अंतर्निहित होस्ट में अन-विशेषाधिकार प्राप्त user namespaces सक्षम होना चाहिए। उदाहरण के लिए, यह हाल के Ubuntu रिलीज़ पर डिफ़ॉल्ट है। चूंकि Seccomp unshare() syscall को ब्लॉक करता है, केवल Seccomp के बिना चलने वाले कंटेनर ही एक नया user namespace बना सकते हैं। संलग्न स्क्रीनशॉट में दिखाया गया कंटेनर Seccomp, AppArmor या SELinux के बिना चलता है।
चित्र 2 - कंटेनर नए user और cgroup namespaces में memory cgroup को माउंट करता है।
उपरोक्त स्क्रीनशॉट में, कंटेनर ने सफलतापूर्वक एक memory cgroup माउंट किया, लेकिन आप देख सकते हैं कि release_agent फ़ाइल माउंटेड निर्देशिका में शामिल नहीं है!
जैसा कि पहले उल्लेख किया गया है, release_agent फ़ाइल केवल रूट cgroup में दिखाई देती है। cgroup namespace में cgroupfs माउंट करने की एक चेतावनी यह है कि आप उस cgroup को माउंट करते हैं जिससे आप संबंधित हैं, रूट cgroup को नहीं।
चित्र 3 - कंटेनर नए user और cgroup namespaces में रूट RDMA cgroup को माउंट कर रहा है।
इस मुद्दे का शोषण करने के लिए, हमें release_agent फ़ाइल में एक दुर्भावनापूर्ण release agent लिखने की आवश्यकता है। जैसा कि ऊपर चित्र 3 में देखा गया है, वह फ़ाइल root के स्वामित्व में है, इसलिए केवल root कंटेनर प्रोसेस ही release agent सेट कर सकते हैं। चित्र 4 कंटेनर को release agent सेट करते हुए दिखाता है, जबकि चित्र 5 एक नॉन-रूट कंटेनर को ऐसा करने में विफल दिखाता है।
चित्र 4 - एक रूट कंटेनर release agent सेट कर रहा है।
चित्र 5 - नॉन-रूट कंटेनर release agent सेट नहीं कर सकता।
एस्केप का अंतिम चरण कॉन्फ़िगर किए गए release_agent को आमंत्रित करना है, जिसके लिए किसी विशेषाधिकार की आवश्यकता नहीं होती है। चूंकि यह चरण हमेशा किया जा सकता है, इसका इस बात पर कोई प्रभाव नहीं पड़ता कि कोई वातावरण CVE-2022-0492 के लिए संवेदनशील है या नहीं, और इसलिए हमने इसे छोड़ने का निर्णय लिया। आप नीचे दिए गए स्क्रीनशॉट में देख सकते हैं कि एक पूर्ण शोषण कैसा दिखता है।
चित्र 6 - user namespaces के माध्यम से कंटेनर एस्केप के लिए CVE-2022-0492 का शोषण..
नए user और cgroup namespaces बनाने के बजाय, एक सरल शोषण संभव है यदि कंटेनर को CAP_SYS_ADMIN क्षमता प्रदान की गई हो। CAP_SYS_ADMIN क्षमता के साथ चलने वाले कंटेनर को cgroupfs माउंट करने की अनुमति है, बिना किसी सवाल के। बोनस के रूप में, आज अधिकांश कंटेनर cgroup namespaces के बिना चलते हैं, जिसका अर्थ है कि माउंटेड cgroup रूट cgroup होस्टिंग और release_agent फ़ाइल होगा।
चित्र 7 - प्रारंभिक cgroup namespace में, cgroupfs माउंट करने से हमेशा रूट cgroup माउंट होगा, भले ही कंटेनर का cgroup कुछ भी हो।
यहां तक कि CAP_SYS_ADMIN क्षमता के साथ, AppArmor और SELinux अभी भी माउंटिंग को रोकते हैं, इसलिए इनमें से किसी के साथ चलने वाले कंटेनर CVE-2022-0492 का शोषण नहीं कर सकते। चित्र 8 AppArmor और SELinux के बिना, और CAP_SYS_ADMIN क्षमता के साथ चलने वाले एक कंटेनर को CVE-2022-0492 का शोषण करके बाहर निकलते हुए दिखाता है।
चित्र 8 - CAP_SYS_ADMIN क्षमता के माध्यम से कंटेनर एस्केप के लिए CVE-2022-0492 का शोषण।
CVE-2022-0492 एक और Linux भेद्यता है जिसका उपयोग कंटेनर एस्केप के लिए किया जा सकता है। सौभाग्य से, बेस्ट प्रैक्टिस का पालन करने वाले वातावरण इस भेद्यता से सुरक्षित हैं। ढीले सुरक्षा नियंत्रण वाले वातावरण जो अविश्वसनीय या सार्वजनिक रूप से उजागर कंटेनरों को होस्ट करते हैं, आश्चर्यजनक रूप से उच्च जोखिम में हैं। हमेशा की तरह, अपने होस्ट को एक फिक्स्ड कर्नेल संस्करण में अपग्रेड करना सबसे अच्छा है।
हम दृढ़ता से अनुशंसा करते हैं कि Seccomp और AppArmor या SELinux में से किसी एक को सक्षम करके कंटेनर चलाएं, ताकि इस भेद्यता और भविष्य की Linux zero-day भेद्यताओं से सुरक्षा मिल सके। Linux कर्नेल में कई विशेषाधिकार वृद्धि भेद्यताओं का उपयोग केवल तभी कंटेनर एस्केप के लिए किया जा सकता है जब कंटेनर को एक नया user namespace बनाने की अनुमति हो, या दूसरे शब्दों में, जब कंटेनर Seccomp के बिना चलता है।
© 2022 - नहीं Sofiane Hamlaooui - दुनिया को एक बेहतर जगह बनाना 🌎
