लिनक्स सर्वर के लिए एकदम सही दुःस्वप्न तब होता है जब हमलावर को बस सर्वर के सिक्योर शेल (SSH) पोर्ट तक पहुंचना होता है, सीधे अंदर घुसना होता है, और उस पर कब्जा करना होता है। यही Alpine Linux के साथ हुआ, जो एक लोकप्रिय हल्का लिनक्स सर्वर है। इसे और भी अपमानजनक बनाते हुए, यह घटना Alpine Linux के GitLab कार्यान्वयन में एक सुरक्षा छेद-आकार की गोली से बचने के कुछ ही दिनों बाद हुई।
जैसा कि सुरक्षा इंजीनियर ग्रेगरी ब्रायंट ने अपनी लिंक्डइन पोस्ट में समझाया: "अधिकांश प्रमाणीकरण बायपास जटिल तर्क श्रृंखलाओं से आते हैं, लेकिन कल का Alpine Linux OpenSSH भेद्यता (CVE-2026-123158) एक ही अक्षर पर आता है: *।"
यदि आप Alpine Linux (या कोई अन्य musl-आधारित डिस्ट्रो) डिफ़ॉल्ट openssh-server पैकेज (कोई प्लगेबल ऑथेंटिकेशन मॉड्यूल, या PAM नहीं) के साथ चलाते हैं और PasswordAuthentication सक्षम है, तो एक हमलावर केवल 257 से 1024 बाइट लंबा पासवर्ड भेजकर पासवर्ड-अक्षम, या केवल-कुंजी खातों में लॉग इन कर सकता है।
Alpine Linux एकमात्र ऑपरेटिंग सिस्टम नहीं है जो musl का उपयोग करता है, जो मानक C लाइब्रेरी (libc) का एक हल्का संस्करण है। अन्य ऑपरेटिंग सिस्टम जो musl का उपयोग करते हैं और संभावित रूप से भेद्य हैं, उनमें Adélie Linux; Void Linux; Sabotage Linux; OpenWrt, एक Android संस्करण; और Yocto Project शामिल हैं, जिसका उपयोग एम्बेडेड लिनक्स वितरण बनाने के लिए किया जाता है।
Wind River, जो वाणिज्यिक एम्बेडेड लिनक्स डिस्ट्रो Wind River Linux का उत्पादन करता है, भी इस मुद्दे की जांच कर रहा है। कंपनी के एक प्रतिनिधि ने मुझे बताया, "Wind River सुरक्षा को गंभीरता से लेता है। हम सक्रिय रूप से रिपोर्ट की गई भेद्यता की समीक्षा कर रहे हैं और इसके संभावित प्रभाव का आकलन कर रहे हैं। हम आवश्यकतानुसार उचित कार्रवाई करेंगे।"
पर्दे के पीछे, जब OpenSSH को PAM के बिना बनाया जाता है, तो यह C लाइब्रेरी के crypt() फ़ंक्शन का उपयोग करके पासवर्ड प्रयास को हैश करके पासवर्ड सत्यापित करता है। फिर यह परिणाम की तुलना खाते के संग्रहीत पासवर्ड फ़ील्ड से करता है। अब तक सब ठीक है।
लेकिन जब कोई कुंजी 256 बाइट से अधिक लंबी होती है, तो musl का crypt() फ़ंक्शन त्रुटि संकेतक के रूप में स्ट्रिंग * लौटाता है। यही उन खातों के पासवर्ड फ़ील्ड में भी होता है जिनका कोई पासवर्ड नहीं है, जैसे कि केवल-कुंजी खाते। इस प्रकार, "हैश" मेल खाता है और लॉगिन सफल हो जाता है, और हमलावर अंदर आ जाता है।
इसका शोषण करने के लिए, हमलावर को केवल ऐसे खाते का नाम चाहिए। हमलावर को मशीन पर कम से कम एक अन्य खाता भी चाहिए जिसमें 5 या 6 पासवर्ड हैश हो, और फिर 257 से 1,024 बाइट का पासवर्ड भेजना होगा। Alpine के अनुसार, पासवर्ड वाला एक उपयोगकर्ता हर पासवर्ड रहित खाते को सुलभ बनाने के लिए पर्याप्त है।
लिनक्स सिस्टम में जो glibc के crypt() का उपयोग करते हैं, जो लगभग सभी हैं, वही प्रयास त्रुटि पर NULL लौटाएगा, जिसे sshd पहले ही अस्वीकार कर देता है, इसलिए Debian, Ubuntu, Fedora, आदि प्रभावित नहीं हैं।
*sshole के अनुसार, वह समूह जिसने समस्या का पता लगाया, यह एक दुष्प्रभाव है जो 2016 से छिपा हुआ है।
Alpine ने कहा कि इसके द्वारा जांचे गए हर रिलीज़ प्रभावित हैं: 3.21 से 3.24, edge, और पुरानी 3.16 से 3.20 शाखाएं। जोखिम के लिए निम्नलिखित आवश्यक है:
अधिकांश मामलों में रूट सीधे उजागर नहीं होता है। यह लगभग Alpine 3.16 से बेस इमेज में root:* के रूप में शिप किया गया है, लेकिन OpenSSH का डिफ़ॉल्ट PermitRootLogin prohibit-password इसे अवरुद्ध करता है। एक अन्य खाता जो रूट बन सकता है, उदाहरण के लिए doas के माध्यम से, अभी भी हमलावर को रूट तक पहुंच प्रदान करता है।
Alpine ने अपनी आधिकारिक tiny-cloud इमेजों, संस्करण 3.18.11 से 3.24.3, को विशेष रूप से भेद्य बताया। ये एक alpine उपयोगकर्ता के साथ आती हैं जिसमें * पासवर्ड फ़ील्ड और पासवर्ड रहित doas होता है। वे पहले बूट पर सुरक्षित होती हैं लेकिन मशीन पर कोई भी 6 हैश होने के बाद शोषण योग्य हो जाती हैं। ऐसा तब हो सकता है जब कोई व्यवस्थापक कंसोल पासवर्ड सेट करता है या जब उपयोगकर्ता डेटा हैशेड पासवर्ड वाला उपयोगकर्ता जोड़ता है, जिसका अर्थ है, अनिवार्य रूप से, उन सभी में।
Alpine ने गुरुवार को 3.21.10, 3.22.8, 3.23.8 और 3.24.4 जारी किए, जिसमें सुरक्षा परिवर्तनों में OpenSSH फिक्स भी शामिल है। इसने 3.16 तक के प्रत्येक रिलीज़ के लिए फिक्स्ड पैकेज भी प्रकाशित किए। Alpine 3.21 का समर्थन 1 नवंबर को समाप्त हो गया।
अभी जारी OpenSSH 10.6p2 sshd में समस्या से बचता है। Alpine की स्थिर शाखाओं में उसी समस्या के लिए एक पैच है। आपको apk upgrade -U -a चलाना चाहिए और फिर th को पुनः आरंभ करना चाहिए