teamos-hub/regresshionयह CVE-2024-6387 के लिए मेरे द्वारा लिखा गया POC है।
Qualys सुरक्षा सलाह
regreSSHion: OpenSSH के सर्वर में RCE, glibc-आधारित Linux सिस्टम पर (CVE-2024-6387)
सारांश SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, 2005 से)
बस विश्वास की एक छलांग ही काफी है
-- The Interrupters, "Leap of Faith"
प्रारंभिक टिप्पणी: OpenSSH दुनिया के सबसे सुरक्षित सॉफ़्टवेयर में से एक है; यह भेद्यता एक अन्यथा लगभग त्रुटिहीन कार्यान्वयन में एक छोटी सी चूक है। इसका defense-in-depth डिज़ाइन और कोड एक आदर्श और प्रेरणा हैं, और हम OpenSSH के डेवलपर्स को उनके अनुकरणीय कार्य के लिए धन्यवाद देते हैं।
हमने OpenSSH के सर्वर (sshd) में एक भेद्यता (सिग्नल हैंडलर रेस कंडीशन) खोजी है: यदि कोई क्लाइंट LoginGraceTime सेकंड (डिफ़ॉल्ट रूप से 120, पुराने OpenSSH संस्करणों में 600) के भीतर प्रमाणित नहीं करता है, तो sshd का SIGALRM हैंडलर अतुल्यकालिक रूप से कॉल होता है, लेकिन यह सिग्नल हैंडलर कई ऐसे फ़ंक्शन कॉल करता है जो async-signal-safe नहीं हैं (उदाहरण के लिए, syslog())। यह रेस कंडीशन sshd को उसकी डिफ़ॉल्ट कॉन्फ़िगरेशन में प्रभावित करती है।
जाँच करने पर, हमें एहसास हुआ कि यह भेद्यता वास्तव में CVE-2006-5051 की प्रतिगमन (regression) है ("OpenSSH 4.4 से पहले सिग्नल हैंडलर रेस कंडीशन दूरस्थ हमलावरों को सेवा से वंचित (क्रैश) करने और संभवतः मनमाना कोड निष्पादित करने की अनुमति देता है"), जिसे 2006 में Mark Dowd ने रिपोर्ट किया था।
यह प्रतिगमन अक्टूबर 2020 (OpenSSH 8.5p1) में कमिट 752250c ("OpenSSH के लिए संशोधित लॉग इंफ्रास्ट्रक्चर") द्वारा पेश किया गया था, जिसने गलती से sigdie() से एक "#ifdef DO_LOG_SAFE_IN_SIGHAND" हटा दिया, जो एक ऐसा फ़ंक्शन है जिसे sshd के SIGALRM हैंडलर द्वारा सीधे कॉल किया जाता है। दूसरे शब्दों में:
OpenSSH < 4.4p1 इस सिग्नल हैंडलर रेस कंडीशन के लिए संवेदनशील है, यदि CVE-2006-5051 के विरुद्ध बैकपोर्ट-पैच नहीं किया गया है, या CVE-2008-4109 के विरुद्ध पैच नहीं किया गया है, जो CVE-2006-5051 का गलत सुधार था;
4.4p1 <= OpenSSH < 8.5p1 इस सिग्नल हैंडलर रेस कंडीशन के लिए संवेदनशील नहीं है (क्योंकि CVE-2006-5051 के पैच द्वारा sigdie() में जोड़ा गया "#ifdef DO_LOG_SAFE_IN_SIGHAND" इस असुरक्षित फ़ंक्शन को सुरक्षित _exit(1) कॉल में बदल देता है);
8.5p1 <= OpenSSH < 9.8p1 इस सिग्नल हैंडलर रेस कंडीशन के लिए फिर से संवेदनशील है (क्योंकि "#ifdef DO_LOG_SAFE_IN_SIGHAND" गलती से sigdie() से हटा दिया गया था)।
यह भेद्यता glibc-आधारित Linux सिस्टम पर दूरस्थ रूप से शोषणीय है, जहाँ syslog() स्वयं async-signal-असुरक्षित फ़ंक्शन (उदाहरण के लिए, malloc() और free()) कॉल करता है: एक बिना प्रमाणीकरण के रूट के रूप में दूरस्थ कोड निष्पादन, क्योंकि यह sshd के विशेषाधिकार प्राप्त कोड को प्रभावित करता है, जो सैंडबॉक्स नहीं है और पूर्ण विशेषाधिकारों के साथ चलता है। हमने किसी अन्य libc या ऑपरेटिंग सिस्टम की जाँच नहीं की है; लेकिन OpenBSD विशेष रूप से संवेदनशील नहीं है, क्योंकि इसका SIGALRM हैंडलर syslog_r() को कॉल करता है, जो syslog() का अधिक async-signal-सुरक्षित संस्करण है, जिसे OpenBSD ने 2001 में बनाया था।
इस भेद्यता का दूरस्थ रूप से शोषण करने के लिए (हमारी जानकारी के अनुसार, CVE-2006-5051 पहले कभी सफलतापूर्वक शोषित नहीं किया गया है), हमने एक दूरदर्शी पेपर, "Delivering Signals for Fun and Profit" से प्रेरणा ली, जिसे 2001 में Michal Zalewski ने प्रकाशित किया था:
https://lcamtuf.coredump.cx/signals.txt
फिर भी, हमें तुरंत तीन बड़ी समस्याओं का सामना करना पड़ा:
सैद्धांतिक दृष्टिकोण से, हमें एक उपयोगी कोड पथ खोजना होगा, जो यदि SIGALRM द्वारा सही समय पर बाधित होता है, तो sshd को असंगत स्थिति में छोड़ देता है, और फिर हमें SIGALRM हैंडलर के अंदर इस असंगत स्थिति का शोषण करना होगा।
व्यावहारिक दृष्टिकोण से, हमें sshd में इस उपयोगी कोड पथ तक पहुँचने का एक तरीका खोजना होगा, और इसे सही समय पर बाधित करने की अपनी संभावनाओं को अधिकतम करना होगा।
समय-निर्धारण दृष्टिकोण से, हमें दूरस्थ रूप से इस उपयोगी कोड पथ को सही समय पर बाधित करने की अपनी संभावनाओं को और बढ़ाने का एक तरीका खोजना होगा।
इन तीन समस्याओं पर ध्यान केंद्रित करने के लिए, बिना तुरंत सभी आधुनिक ऑपरेटिंग सिस्टम सुरक्षाओं (विशेष रूप से, ASLR और NX) से लड़े बिना, हमने पहले पुराने OpenSSH संस्करणों को i386 पर शोषित करने का निर्णय लिया, और फिर इस अनुभव के आधार पर, हाल के संस्करणों को:
पहला, "SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3", "debian-30r6-dvd-i386-binary-1_NONUS.iso" से: यह पहला Debian संस्करण है जिसमें विशेषाधिकार पृथक्करण (privilege separation) डिफ़ॉल्ट रूप से सक्षम है और जो उस युग की सभी गंभीर भेद्यताओं (विशेष रूप से, CVE-2003-0693 और CVE-2002-0640) के विरुद्ध पैच किया गया है।
इस संस्करण का दूरस्थ रूप से शोषण करने के लिए, हम SIGALRM के साथ free() कॉल को बाधित करते हैं (sshd के सार्वजनिक-कुंजी पार्सिंग कोड के अंदर), हीप को असंगत स्थिति में छोड़ देते हैं, और SIGALRM हैंडलर के अंदर free() की एक और कॉल के दौरान इस असंगत स्थिति का शोषण करते हैं।
हमारे प्रयोगों में, इस रेस कंडीशन को जीतने के लिए औसतन ~10,000 प्रयास लगते हैं; अर्थात, प्रति 600 सेकंड (LoginGraceTime) में 10 कनेक्शन (MaxStartups) स्वीकार किए जाने पर, एक दूरस्थ रूट शेल प्राप्त करने में औसतन ~1 सप्ताह लगता है।
दूसरा, "SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3", "ubuntu-6.06.1-server-i386.iso" से: यह अंतिम Ubuntu संस्करण है जो अभी भी CVE-2006-5051 ("OpenSSH 4.4 से पहले सिग्नल हैंडलर रेस कंडीशन") के लिए संवेदनशील है।
इस संस्करण का दूरस्थ रूप से शोषण करने के लिए, हम SIGALRM के साथ pam_start() कॉल को बाधित करते हैं, PAM की एक संरचना को असंगत स्थिति में छोड़ देते हैं, और SIGALRM हैंडलर के अंदर pam_end() कॉल के दौरान इस असंगत स्थिति का शोषण करते हैं।
हमारे प्रयोगों में, इस रेस कंडीशन को जीतने के लिए औसतन ~10,000 प्रयास लगते हैं; अर्थात, प्रति 120 सेकंड (LoginGraceTime) में 10 कनेक्शन (MaxStartups) स्वीकार किए जाने पर, एक दूरस्थ रूट शेल प्राप्त करने में औसतन ~1-2 दिन लगते हैं।
अंत में, "SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2", "debian-12.5.0-i386-DVD-1.iso" से: यह वर्तमान Debian स्थिर संस्करण है, और यह CVE-2006-5051 की प्रतिगमन के लिए संवेदनशील है।
इस संस्करण का दूरस्थ रूप से शोषण करने के लिए, हम SIGALRM के साथ malloc() कॉल को बाधित करते हैं (sshd के सार्वजनिक-कुंजी पार्सिंग कोड के अंदर), हीप को असंगत स्थिति में छोड़ देते हैं, और SIGALRM हैंडलर के अंदर malloc() की एक और कॉल के दौरान (अधिक सटीक रूप से, syslog() के अंदर) इस असंगत स्थिति का शोषण करते हैं।
हमारे प्रयोगों में, इस रेस कंडीशन को जीतने के लिए औसतन ~10,000 प्रयास लगते हैं, इसलिए प्रति 120 सेकंड (LoginGraceTime) में 100 कनेक्शन (MaxStartups) स्वीकार किए जाने पर ~3-4 घंटे लगते हैं। अंततः, एक दूरस्थ रूट शेल प्राप्त करने में औसतन ~6-8 घंटे लगते हैं, क्योंकि हम केवल आधे समय glibc का पता सही ढंग से अनुमान लगा सकते हैं (ASLR के कारण)।
यह शोध अभी भी कार्य प्रगति पर है:
हमने केवल वर्चुअल मशीनों को लक्षित किया है, बेयर-मेटल सर्वरों को नहीं, ज्यादातर स्थिर नेटवर्क लिंक पर (~10ms पैकेट जिटर);
हमें विश्वास है कि हमारे एक्सप्लॉइट्स के विभिन्न पहलुओं में काफी सुधार किया जा सकता है;
हमने amd64 एक्सप्लॉइट पर काम शुरू कर दिया है, जो मजबूत ASLR के कारण बहुत कठिन है।
amd64 पर अपना काम शुरू करने के कुछ दिनों बाद, हमने OpenSSH के सार्वजनिक Bugzilla में निम्नलिखित बग रिपोर्ट देखी, जो sshd के SIGALRM हैंडलर में डेडलॉक के बारे में थी:
https://bugzilla.mindrot.org/show_bug.cgi?id=3690
इसलिए हमने OpenSSH के डेवलपर्स से तुरंत संपर्क करने का निर्णय लिया (उन्हें बताने के लिए कि यह डेडलॉक एक शोषणीय भेद्यता के कारण होता है), हमने अपना amd64 काम रोक दिया, और यह सलाह (advisory) लिखना शुरू कर दिया।