LXD के माध्यम से Linux विशेषाधिकार वृद्धि

अवलोकन

Linux प्रणालियों पर स्थानीय lxd समूह के सदस्यों के पास अपने विशेषाधिकारों को रूट तक बढ़ाने के कई रास्ते हैं। इस रिपॉजिटरी में पूरी तरह से स्वचालित स्थानीय रूट शोषण के उदाहरण हैं। भेद्यता और शोषण वॉक-थ्रू का विस्तृत विवरण मेरे ब्लॉग यहाँ पर उपलब्ध है।

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

मेरा मानना है कि शोषण के संस्करण 2 के साथ मेरी रणनीति अद्वितीय है, और ऊपर लिंक किए गए ब्लॉग में विस्तृत स्पष्टीकरण लिखने के लिए (कम से कम मेरे लिए) पर्याप्त दिलचस्प थी।

• lxd_rootv1.sh होस्ट / फाइलसिस्टम को एक कंटेनर में माउंट करता है, जहां होस्ट के निम्न-विशेषाधिकार उपयोगकर्ता के पास रूट एक्सेस होता है। यह रूट एक्सेस होस्ट पर वापस मैप होता है, जिससे वर्तमान उपयोगकर्ता को /etc/sudoers फ़ाइल में जोड़ा जा सकता है। यह मुझसे पहले दूसरों द्वारा शोषित किया गया है।
• lxd_rootv2.py होस्ट के systemd प्राइवेट UNIX सॉकेट को एक कंटेनर में माउंट करता है और फिर LXD प्रॉक्सी डिवाइसों के माध्यम से वापस होस्ट पर लौटाता है। इन प्रॉक्सी डिवाइसों के पास रूट विशेषाधिकार होते हैं, और वे सॉकेट संचार के दौरान अपनी क्रेडेंशियल्स पास करते हैं, आरंभिक निम्न-विशेषाधिकार उपयोगकर्ता की क्रेडेंशियल्स के विपरीत। इसका दुरुपयोग एक अस्थायी systemd सेवा बनाने के लिए किया जाता है जो वर्तमान उपयोगकर्ता को /etc/sudoers फ़ाइल में जोड़ता है।

उपयोग

दोनों शोषणों के लिए एक कंटेनर आवश्यक है, इसलिए पहले एक बनाएं। फिर, होस्ट OS से शोषण को पहले तर्क के रूप में कंटेनर के नाम के साथ चलाएं।

# Exploit with v1
$ bash lxd_rootv1.sh <container name>

# Exploit with v2
$ python3 lxd_rootv2.py <container name>

पैकेज अनुरक्षक प्रतिक्रिया

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

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

श्रेय

मैं LXD का शोषण करने वाला पहला व्यक्ति नहीं हूं। यह 2016 से कई GitHub टिकटों में एक चिंता के रूप में उठाया गया है:

• https://github.com/lxc/lxd/issues/2003
• https://github.com/lxc/lxd/issues/3844

जहाँ तक मैं बता सकता हूं, वह पहला लिंक इस जोखिम की पहचान करने वाला पहला व्यक्ति (simpoir) है।

@reboare ने मेरे v1 शोषण के समान विधि का उपयोग करके LXD का शोषण करने के बारे में एक अच्छा ब्लॉग लिखा, इससे बहुत पहले मैंने किया:

• https://reboare.github.io/lxd/lxd-escape.html

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

उपचार

इनमें से किसी भी भेद्यता का कोई आधिकारिक समाधान नहीं है। LXD का उपयोग करने वाले किसी भी व्यक्ति को पता होना चाहिए कि उपयोगकर्ताओं को lxd समूह में जोड़ना अनिवार्य रूप से उन्हें रूट में बदलना है।

यदि आप एकल-उपयोगकर्ता होस्ट पर LXD का उपयोग कर रहे हैं, जैसे कि डेस्कटॉप, तो बेहतर होगा कि lxd समूह का बिल्कुल भी उपयोग न करें और जब आपको API से बात करने की आवश्यकता हो तो sudo चलाएं।

साझा वातावरण के लिए जहां कई लोग कंटेनरों पर काम कर रहे हैं, नेस्टेड वातावरण बनाना सबसे अच्छा हो सकता है। LXD समूह का प्रत्येक व्यक्तिगत उपयोगकर्ता अपने स्वयं के वातावरण का शोषण करने में सक्षम होगा, लेकिन फिर दूसरों का शोषण करने के लिए उस कंटेनर से बाहर निकलने के लिए अधिक मेहनत करनी होगी।