sshole: ثغرة في OpenSSH تتيح دخول Alpine Linux دون كلمة مرور

يظهر الخلل حين يتحقق OpenSSH من كلمة مرور لحساب لا ينبغي أن يقبلها. فلا يجد البيانات اللازمة، ويستخدم معلومات حساب آخر للتحقق. وإذا كان طول كلمة المرور بين 257 و1024 بايت، تعيد الدالة المسؤولة في musl علامة نجمة للدلالة على خطأ. ولأن الرمز نفسه موجود في الحساب المحمي، يعتبر الخادم القيمتين متطابقتين ويسمح بالدخول.

تعود جذور المشكلة إلى عام 2012، حين غيّرت musl طريقة الإبلاغ عن بعض الأخطاء وفرضت حدًا لطول كلمات المرور لتفادي هجمات حجب الخدمة. وبعد أربع سنوات أدخل OpenSSH تعديلات تمنع معرفة المستخدمين الموجودين عبر قياس أزمنة الاستجابة. وفي 2022 عدّلت Alpine إعداد حساب المدير للسماح بالدخول بمفاتيح SSH. كانت حلولًا لمشكلات مختلفة، لكنها تفاعلت بصورة غير متوقعة.

من المعرضون للخطر

استخدام Alpine لا يعني بالضرورة أن النظام عرضة للخطر. فبحسب Check Point يجب تحقق عدة شروط معًا: أن يعمل OpenSSH دون PAM، وأن يقبل كلمات المرور، وأن يصادف حسابًا يحمل النجمة. كما يجب وجود حساب محلي نشط آخر ببصمة كلمة مرور مولدة بـ SHA-256 أو SHA-512. أما الأنظمة التي تعطّل المصادقة بكلمة المرور أو تستخدم PAM فخارج هذا السيناريو.

قد تكون العواقب خطيرة إذا كان الحساب المخترق يملك صلاحيات مرتفعة. وتضرب Alpine مثالًا ببعض الصور السحابية الرسمية التي يستطيع فيها المستخدم alpine تنفيذ أوامر المدير عبر doas دون كلمة مرور. هذه الصور آمنة عند أول تشغيل، لكنها قد تصبح عرضة للخطر إذا أُعدّ لاحقًا حساب ببصمة كلمة مرور متوافقة. وتقول شركة Previdian إنها رصدت ثماني محاولات من عنوان IP واحد، وأكدت دخولًا بصلاحيات المدير على أحد خوادمها الخادعة.

أصدر OpenSSH النسخة 10.6p2، ووزعت Alpine تحديثات لعدة فروع بينها قديمة. ولا يكفي تثبيت الإصلاحات، بل يجب إعادة تشغيل خدمة SSH. وإن تعذر التحديث، يوصى بتعطيل المصادقة بكلمة المرور وإعادة تشغيل الخدمة، بعد التأكد من أن الدخول بالمفاتيح يعمل.