OpenSSH تطلق تحديثاً حرجاً لمعالجة ثغرة تجاوز كلمة المرور على Alpine Linux
أصدرت OpenSSH تحديثاً حرجاً للإصدار 10.6p2 لمعالجة ثغرة تتيح للمهاجمين تسجيل الدخول إلى حسابات دون كلمات مرور على بعض خوادم Alpine Linux التي تشغّل حزمة openssh-server القياسية. لاستغلال هذه الثغرة، يحتاج المهاجمون إلى وصول إلى الشبكة، واسم الحساب، وكلمة مرور يتراوح طولها بين 257 و1,024 بايت.
تظهر الثغرة عندما يتحقق خادم OpenSSH (sshd) من كلمات المرور دون استخدام واجهة Pluggable Authentication Module (PAM)، مع تفعيل تسجيل الدخول بكلمة المرور، ووجود حساب آخر واحد على الأقل على الجهاز يمتلك كلمة مرور. تُبنى حزمة openssh-server في Alpine دون PAM، ويكون تسجيل الدخول بكلمة المرور مفعّلاً افتراضياً.
ترتبط هذه الثغرة بطريقة تفاعل sshd مع musl، مكتبة C التي تستخدمها Alpine. لا تتأثر الأنظمة غير المبنية على musl، بما في ذلك تلك المبنية على glibc أو التي تتحقق من كلمات المرور عبر PAM، وفقاً لديمين ميلر من مشروع OpenSSH.
نصح ميلر مستخدمي الأنظمة المتأثرة بأن “يضبطوا PasswordAuthentication=no أو يعطّلوا SSH على هذه الأنظمة فوراً”. حتى الآن، لم تُبلَّغ أي هجمات تستغل هذه الثغرة.
شروط التعرض للثغرة
يحدد الاستشارة الأمنية لـ Alpine أربعة شروط يجب توفرها ليكون الخادم عرضة للثغرة:
- يشغّل الخادم حزمة openssh-server المبنية دون PAM أو يشغّل openssh-server-pam مع ضبط UsePAM على no.
- يجب ضبط PasswordAuthentication على yes، وهو الإعداد الافتراضي لـ OpenSSH.
- يجب أن يحتوي حساب على `*` في حقل كلمة المرور، ما يشير إلى عدم تعيين كلمة مرور.
- يجب أن يمتلك حساب محلي آخر واحد على الأقل تجزئة كلمة مرور تبدأ بـ `$5$` أو `$6$`.
يحتاج المهاجمون أيضاً إلى اسم حساب لا يملك كلمة مرور. إذا كان أحد الحسابات يملك كلمة مرور، فيمكنه كشف جميع الحسابات التي لا تملك كلمة مرور. تذكر الاستشارة أن الهجوم يمكن أن ينجح في كل محاولة باتصال واحد.
تشمل الحسابات التي لا تملك كلمات مرور على Alpine:
- مستخدمي المفاتيح فقط الذين أُنشئوا باستخدام adduser دون كلمة مرور أو باستخدام usermod -p ‘*’
- المستخدمون من خدمة دليل عبر musl-nscd، لأنهم يفتقرون إلى إدخال shadow
- حساب root، الذي ضُبط كـ root:* في الصورة الأساسية منذ نحو Alpine 3.16
- مستخدم alpine في صور السحابة الرسمية المبنية باستخدام tiny-cloud
رغم أن root محمي بإعداد PermitRootLogin prohibit-password الافتراضي، يمكن الوصول إليه مباشرة إذا ضُبط PermitRootLogin yes. تصبح هذه الحماية غير فعالة إذا كان بإمكان حساب مكشوف تصعيد الصلاحيات إلى root، مثل عبر doas.
تمنح صور tiny-cloud من الإصدارات 3.18.11 إلى 3.24.3 مستخدم alpine وصول doas دون كلمة مرور. تكون هذه الصور آمنة عند الإقلاع الأول لكنها تصبح عرضة للثغرة بمجرد وجود أي تجزئة `$6$` على الجهاز، على سبيل المثال بعد أن يعيّن مسؤول كلمة مرور وحدة التحكم. يمكن للمهاجم حينها تسجيل الدخول باسم alpine واستخدام doas للحصول على صلاحيات الجذر.
لا تتأثر الحاويات التي لا تشغّل sshd، والأنظمة التي ضُبط فيها PasswordAuthentication على no، وصور السحابة المهيأة عبر cloud-init. الحسابات المقفلة بـ `!` في /etc/shadow آمنة أيضاً، وكذلك الأجهزة التي لا يملك فيها أي حساب تجزئة كلمة مرور بنمط `$`.
الثغرة ليست حصرية لـ Alpine. أشار أوزغون كولتكين من Wakefield، الذي أبلغ عن المشكلة، إلى أنه يجب فحص أنظمة أخرى مبنية على musl مثل OpenWrt وBuildroot وYocto.
إصلاح الثغرة
لحل المشكلة على Alpine، يجب على المستخدمين تحديث حزمهم وإعادة تشغيل خدمة sshd:
- تحديث الحزم: apk upgrade -U -a
- إعادة تشغيل الخادم: rc-service sshd restart
تتضمن الإصدارات الفرعية 3.21.10 و3.22.8 و3.23.8 و3.24.4 الحزمة المُصلحة بالفعل. رغم أن الفروع من 3.16 إلى 3.21 تجاوزت نهاية دعمها، فقد تلقت أيضاً حزماً مُصلحة.
إذا لم تكن التحديثات الفورية ممكنة، فإن تعطيل تسجيل الدخول بكلمة المرور يمكن أن يمنع الهجوم. يجب على المستخدمين أولاً التأكد من أن تسجيل الدخول بمفتاح SSH يعمل والحفاظ على جلستهم الحالية حتى ينجح تسجيل دخول جديد. ثم يضبطون PasswordAuthentication على no، ويتحققون من الإعدادات باستخدام sshd -t، ويعيدون تشغيل sshd.
توفر الاستشارة أوامر لإضافة هذا الإعداد في ملف drop-in في /etc/ssh/sshd_config.d. وتقترح أيضاً تغيير كل سطر PasswordAuthentication في /etc/ssh/sshd_config من yes إلى no. بعد إجراء هذه التغييرات، يجب أن يعيد sshd -T | grep -i passwordauthentication النتيجة passwordauthentication no.
يُنصح المستخدمون بفحص /var/log/messages بحثاً عن إدخالات sshd تشير إلى قبول تسجيل الدخول بكلمة مرور لحسابات لا تملك كلمات مرور. على الأجهزة المكشوفة، يُوصى أيضاً بمراجعة استخدام doas، والمستخدمين المنشئين حديثاً، والملفات، والمفاتيح المصرح بها.
تحذر الاستشارة: «إذا لم تتمكن من استبعاد تسجيل دخول، فتعامل مع الجهاز على أنه مخترق».
فهم آلية الثغرة
توجد الثغرة لأن sshd يتحقق من كلمات المرور مباشرة دون PAM. يقوم بتجزئة محاولة كلمة المرور باستخدام crypt()، دالة مكتبة C التي تحول كلمة المرور إلى شكلها المخزن، ويقارن النتيجة بالحقل المخزن.
يحتوي الحساب الذي لا يملك كلمة مرور على `*` فقط في ذلك الحقل، وهو أقصر من أن يخزن salt. وبالتالي، يستخدم sshd الـ salt من حساب آخر يملك تجزئة صالحة.
بالنسبة لنوعي التجزئة `$5$` و`$6$`، لا تقبل crypt() في musl كلمات مرور أطول من 256 بايت، وتعيد `*` للإشارة إلى خطأ. يتطابق هذا `*` مع `*` المخزن، ما يسمح لـ sshd بقبول تسجيل الدخول. الحد الأقصى لطول كلمات المرور هو حد sshd البالغ 1,024 بايت.
ينبع هذا السلوك من تغيير في musl أُجري في 9 أغسطس 2012، جعل استدعاء crypt() الفاشل يعيد «تجزئة غير قابلة للمطابقة بدلاً من NULL». أُدخل حد 256 بايت في 29 أغسطس 2012، لحماية الخوادم من هجمات حجب الخدمة. أُدخلت طريقة استعارة الـ salt في تغيير لـ OpenSSH في 15 يوليو 2016 عالج CVE-2016-6210، وهي ثغرة أتاحت للمهاجمين اكتشاف أسماء المستخدمين الموجودة. أشار كولتكين إلى أن هذه المشكلة مستمرة منذ ذلك الحين.
يمنع تغيير الشيفرة في الإصدار 10.6p2 sshd من قبول تطابق عندما يكون الحقل المخزن أقصر من أربعة أحرف. تصف OpenSSH هذا بأنه حل مؤقت، وتذكر أن السبب الجذري يقع خارج sshd.
استجابة سريعة للثغرة
أصبح فريق ميلر على علم بالثغرة في وقت سابق من الأسبوع وعجّل الإصلاح. في إعلان الإصدار، ذكر أن الفريق ينظر الآن إلى فترات الحظر الطويلة على أنها خطيرة وتفيد المهاجمين بشكل أساسي، لأنهم لاحظوا وكلاء ذكاء اصطناعي يكتشفون الأخطاء نفسها في غضون ساعات.
لم يكن قد خُصص معرّف CVE للثغرة حتى 5 نوفمبر.
المصدر: The Hacker News