teamos-hub/regresshionهذا هو POC الذي كتبته لـ CVE-2024-6387
Qualys Security Advisory
regreSSHion: تنفيذ تعليمات برمجية عن بُعد في خادم OpenSSH على أنظمة Linux المبنية على glibc (CVE-2024-6387)
ملخص SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, from 2005)
كل ما يتطلبه الأمر هو قفزة إيمان
-- The Interrupters, "Leap of Faith"
ملاحظة أولية: OpenSSH هو أحد أكثر البرمجيات أمانًا في العالم؛ هذه الثغرة هي مجرد زلّة واحدة في تنفيذ شبه خالٍ من العيوب. ويُعد تصميمها القائم على الدفاع المتعمّق ورمزها البرمجي نموذجًا ومصدر إلهام، ونشكر مطوّري OpenSSH على عملهم المثالي.
اكتشفنا ثغرة (حالة تسابق في معالج الإشارات) في خادم OpenSSH (sshd): إذا لم يقم العميل بالمصادقة خلال LoginGraceTime ثانية (120 افتراضيًا، 600 في إصدارات OpenSSH القديمة)، عندها يتم استدعاء معالج SIGALRM الخاص بـ sshd بشكل غير متزامن، لكن معالج الإشارة هذا يستدعي دوالًا مختلفة ليست آمنة للإشارات غير المتزامنة (على سبيل المثال، syslog()). تؤثر حالة التسابق هذه على sshd في تكوينه الافتراضي.
عند التحقيق، أدركنا أن هذه الثغرة هي في الواقع ارتداد لـ CVE-2006-5051 ("حالة تسابق في معالج الإشارات في OpenSSH قبل 4.4 تتيح للمهاجمين عن بُعد التسبب في رفض الخدمة (تعطل)، وربما تنفيذ كود عشوائي")، والتي أُبلغ عنها في 2006 بواسطة Mark Dowd.
تم إدخال هذا الارتداد في أكتوبر 2020 (OpenSSH 8.5p1) عبر الالتزام 752250c ("revised log infrastructure for OpenSSH")، والذي أزال عن طريق الخطأ "#ifdef DO_LOG_SAFE_IN_SIGHAND" من sigdie()، وهي دالة يتم استدعاؤها مباشرة بواسطة معالج SIGALRM الخاص بـ sshd. بعبارة أخرى:
OpenSSH < 4.4p1 معرّض لحالة التسابق هذه في معالج الإشارات، إذا لم يتم تصحيحه بنقل التصحيح الخاص بـ CVE-2006-5051، أو لم يتم تصحيحه ضد CVE-2008-4109، الذي كان تصحيحًا غير صحيح لـ CVE-2006-5051؛
4.4p1 <= OpenSSH < 8.5p1 غير معرّض لحالة التسابق هذه في معالج الإشارات (لأن "#ifdef DO_LOG_SAFE_IN_SIGHAND" الذي أُضيف إلى sigdie() بواسطة تصحيح CVE-2006-5051 حوّل هذه الدالة غير الآمنة إلى استدعاء آمن _exit(1))؛
8.5p1 <= OpenSSH < 9.8p1 معرّض مرة أخرى لحالة التسابق هذه في معالج الإشارات (لأن "#ifdef DO_LOG_SAFE_IN_SIGHAND" أُزيل عن طريق الخطأ من sigdie()).
هذه الثغرة قابلة للاستغلال عن بُعد على أنظمة Linux المبنية على glibc، حيث تستدعي syslog() نفسها دوالًا غير آمنة للإشارات غير المتزامنة (على سبيل المثال، malloc() و free()): تنفيذ كود عن بُعد غير مصادَق به بصلاحية root، لأنها تؤثر على الكود المميّز الخاص بـ sshd، وهو غير معزول ويعمل بصلاحيات كاملة. لم نتحقق من أي libc أو نظام تشغيل آخر؛ لكن OpenBSD ليس معرضًا بشكل ملحوظ، لأن معالج SIGALRM الخاص به يستدعي syslog_r()، وهي نسخة أكثر أمانًا للإشارات غير المتزامنة من syslog() ابتكرتها 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 يكون فيه فصل الامتيازات مفعّلاً افتراضيًا ويكون مصححًا ضد جميع الثغرات الحرجة في تلك الحقبة (خاصة CVE-2003-0693 و CVE-2002-0640).
لاستغلال هذا الإصدار عن بُعد، نقاطع استدعاءً لـ free() بواسطة SIGALRM (داخل كود تحليل المفاتيح العامة في sshd)، ونترك الكومة في حالة غير متناسقة، ونستغل هذه الحالة غير المتناسقة أثناء استدعاء آخر لـ free()، داخل معالج SIGALRM.
في تجاربنا، يستغرق الأمر حوالي 10,000 محاولة في المتوسط للفوز بحالة التسابق هذه؛ أي مع 10 اتصالات (MaxStartups) مقبولة كل 600 ثانية (LoginGraceTime)، يستغرق الأمر حوالي أسبوع في المتوسط للحصول على قشرة root عن بُعد.
ثانيًا، "SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3"، من "ubuntu-6.06.1-server-i386.iso": هذا هو آخر إصدار من Ubuntu لا يزال معرضًا لـ CVE-2006-5051 ("حالة تسابق في معالج الإشارات في OpenSSH قبل 4.4").
لاستغلال هذا الإصدار عن بُعد، نقاطع استدعاءً لـ pam_start() بواسطة SIGALRM، ونترك أحد هياكل PAM في حالة غير متناسقة، ونستغل هذه الحالة غير المتناسقة أثناء استدعاء لـ pam_end()، داخل معالج SIGALRM.
في تجاربنا، يستغرق الأمر حوالي 10,000 محاولة في المتوسط للفوز بحالة التسابق هذه؛ أي مع 10 اتصالات (MaxStartups) مقبولة كل 120 ثانية (LoginGraceTime)، يستغرق الأمر حوالي 1-2 يوم في المتوسط للحصول على قشرة root عن بُعد.
أخيرًا، "SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2"، من "debian-12.5.0-i386-DVD-1.iso": هذا هو إصدار Debian المستقر الحالي، وهو معرض لارتداد CVE-2006-5051.
لاستغلال هذا الإصدار عن بُعد، نقاطع استدعاءً لـ malloc() بواسطة SIGALRM (داخل كود تحليل المفاتيح العامة في sshd)، ونترك الكومة في حالة غير متناسقة، ونستغل هذه الحالة غير المتناسقة أثناء استدعاء آخر لـ malloc()، داخل معالج SIGALRM (بتعبير أدق، داخل syslog()).
في تجاربنا، يستغرق الأمر حوالي 10,000 محاولة في المتوسط للفوز بحالة التسابق هذه، أي حوالي 3-4 ساعات مع 100 اتصال (MaxStartups) مقبول كل 120 ثانية (LoginGraceTime). في النهاية، يستغرق الأمر حوالي 6-8 ساعات في المتوسط للحصول على قشرة root عن بُعد، لأننا لا نستطيع تخمين عنوان glibc بشكل صحيح إلا في نصف المرات (بسبب ASLR).
لا يزال هذا البحث عملاً قيد التقدم:
استهدفنا الأجهزة الافتراضية فقط، وليس الخوادم الفعلية، عبر رابط شبكة مستقر في الغالب (~10ms تذبذب في الحزم)؛
نحن مقتنعون بأن الجوانب المختلفة لاستغلالاتنا يمكن تحسينها بشكل كبير؛
بدأنا العمل على استغلال amd64، وهو أصعب بكثير بسبب قوة ASLR الأكبر.
بعد أيام قليلة من بدء عملنا على amd64، لاحظنا تقرير الخطأ التالي (في نظام Bugzilla العام لـ OpenSSH)، حول توقف تام في معالج SIGALRM الخاص بـ sshd:
https://bugzilla.mindrot.org/show_bug.cgi?id=3690
لذلك قررنا الاتصال بمطوّري OpenSSH فورًا (لإعلامهم بأن هذا التوقف التام ناتج عن ثغرة قابلة للاستغلال)، وأوقفنا عملنا على amd64، وبدأنا في كتابة هذه النشرة.
لكن هذا ليس من طبيعتي، أنا أتحرر
-- The Interrupters, "Haven't Seen the Last of Me"
معالج SIGALRM في هذا الإصدار من OpenSSH يستدعي packet_close()، الذي يستدعي buffer_free()، الذي يستدعي xfree() وبالتالي free()، وهي ليست آمنة للإشارات غير المتزامنة: