OpenSSH در یک وصله اضطراری، آسیب‌پذیری دور زدن احراز هویت با رمز عبور در سیستم‌های musl را برطرف می‌کند
وصله اضطراری OpenSSH نسخه 10.6p2، آسیب‌پذیری امنیتی را که به مهاجمان اجازه می‌داد بدون رمز عبور به حساب‌های کاربری وارد شوند، برطرف می‌کند. این مشکل که ناشی از ترکیب سه تصمیم طراحی قدیمی بوده، پس از ده سال کشف شده و منجر به اختلاف نظر بین OpenSSH و musl بر سر مسئولیت شده است.
جزئیات آسیب‌پذیری
این آسیب‌پذیری در سیستم‌هایی که از musl، مانند Alpine Linux، استفاده می‌کنند، وجود داشت. مهاجمان می‌توانستند با ارسال یک رمز عبور بسیار طولانی (بین ۲۵۷ تا ۱۰۲۴ بایت) به حساب‌های کاربری که رمز عبور برای آن‌ها تنظیم نشده بود، دسترسی پیدا کنند. این دسترسی به صورت مداوم و با هر بار تلاش برای اتصال امکان‌پذیر بود.
Damien Miller، توسعه‌دهنده OpenSSH، در اطلاعیه‌ای اعلام کرد که این مشکل به تازگی کشف شده و نسخه 10.6p2 در تاریخ ۵ نوامبر منتشر شده است. این آسیب‌پذیری توسط Özgün Kültekin از شرکت امنیتی Wakefield کشف و با نام مستعار “*sshole” و شناسه CVE-2026-123158 ثبت شده است.
ریشه‌های تاریخی و فنی
ریشه این مشکل به رویه‌های دهه ۱۹۸۰ بازمی‌گردد. در سیستم‌های یونیکس، حساب‌های کاربری که نباید با رمز عبور وارد می‌شدند، در فیلد رمز عبور خود یک علامت ستاره (*) داشتند. این ستاره یک هش رمز عبور نبود و هیچ رمز عبوری نمی‌توانست با آن مطابقت داشته باشد. این رویه تا به امروز ادامه یافته است.
بسیاری از توزیع‌های لینوکس، احراز هویت رمز عبور را به ماژول‌های PAM (Pluggable Authentication Modules) واگذار می‌کنند. اما sshd که از PAM استفاده نمی‌کند، باید احراز هویت را به صورت مستقل انجام دهد. این کار با استفاده از تابع crypt() (که رمز عبور را به هش تبدیل می‌کند) و مقایسه آن با مقدار ذخیره شده در فیلد رمز عبور انجام می‌شود. ترکیب سه تصمیم مستقل و منطقی در طول زمان، منجر به بروز این مشکل شده است.
در آگوست ۲۰۱۲، musl برای جلوگیری از کرش کردن برنامه‌ها در صورت بازگشت مقدار null از تابع crypt()، تغییراتی اعمال کرد و در صورت شکست، ستاره () را برمی‌گرداند. بیست روز بعد، musl پشتیبانی از SHA-512 را اضافه کرد و برای جلوگیری از کند شدن سرور توسط رمزهای عبور بسیار طولانی، حداکثر طول رمز عبور را ۲۵۶ بایت تعیین کرد. هر رمز عبوری که از این حد تجاوز می‌کرد، ناموفق تلقی شده و ستاره () برگردانده می‌شد. در سال ۲۰۱۶، برای رفع آسیب‌پذیری CVE-2016-6210 که امکان تشخیص وجود حساب کاربری از طریق زمان پاسخ‌دهی را فراهم می‌کرد، sshd در صورت عدم وجود هش قابل استفاده برای یک حساب کاربری، از “نمک” (salt) یک حساب کاربری دیگر استفاده می‌کرد تا هش را محاسبه کند.
نحوه سوءاستفاده
ترکیب این عوامل به این صورت عمل می‌کرد: فیلد رمز عبور حساب‌های بدون رمز، ستاره () بود. این ستاره به اندازه‌ای کوتاه بود که نمی‌توانست به عنوان نمک استفاده شود. sshd از نمک $6$ یک حساب کاربری دیگر استفاده می‌کرد و رمز عبور طولانی‌تر از ۲۵۶ بایت را به تابع crypt() در musl ارسال می‌کرد. musl ستاره () را برمی‌گرداند. این ستاره با ستاره موجود در فیلد رمز عبور حساب کاربری مطابقت پیدا می‌کرد و دسترسی مجاز بود. این مسیر تنها در صورتی مسدود می‌شد که هیچ هش $5$ یا $6$ برای استفاده از نمک در سیستم وجود نداشت.
این آسیب‌پذیری تنها زمانی رخ می‌داد که چهار شرط همزمان برقرار بودند: سیستم از musl استفاده می‌کرد و sshd از PAM بهره نمی‌برد (این تنظیمات پیش‌فرض در بسته openssh-server در Alpine است، اما حتی با نصب openssh-server-pam و تنظیم UsePAM no نیز این مشکل وجود داشت)؛ ورود با رمز عبور مجاز بود (که پیش‌فرض است)؛ فیلد رمز عبور یک حساب کاربری ستاره (*) بود (مانند حساب root در Alpine 3.16 به بعد یا حساب‌هایی که فقط از کلید استفاده می‌کردند)؛ و یک حساب کاربری دیگر با هش $5$ یا $6$ وجود داشت.
سیستم‌هایی که از glibc استفاده می‌کردند، از احراز هویت PAM بهره می‌بردند، ورود با رمز عبور را غیرفعال کرده بودند، یا در محیط کانتینر بدون اجرای sshd بودند، تحت تأثیر این آسیب‌پذیری قرار نمی‌گرفتند. همچنین، ایمیج‌هایی که با cloud-init پیکربندی شده بودند و Dropbear پس از سال ۲۰۱۹، از این مشکل مصون بودند.
هشدار برای کاربران Alpine
ایمیج‌های ابری رسمی Alpine نیاز به توجه ویژه دارند. ایمیج‌های tiny-cloud در نسخه‌های 3.18.11 تا 3.24.3 دارای حساب کاربری alpine با فیلد رمز عبور ستاره (*) و ابزار doas (برای ارتقاء دسترسی به root) بدون نیاز به رمز عبور بودند. در حالی که راه‌اندازی اولیه سیستم امن بود، اما به محض ایجاد یک هش $6$ در سیستم (مثلاً با تنظیم رمز عبور برای مدیر سیستم)، مهاجم می‌توانست ابتدا با حساب alpine وارد شود و سپس با استفاده از doas به root دسترسی پیدا کند. تنظیم پیش‌فرض OpenSSH یعنی PermitRootLogin prohibit-password، از ورود مستقیم به root جلوگیری می‌کرد، اما این مسیر دور زدن را مسدود نمی‌نمود.
کاربران Alpine توصیه می‌شود که سیستم خود را به‌روزرسانی کنند:apk upgrade -U -a
به‌روزرسانی بسته‌ها نیازی به راه‌اندازی مجدد sshd در حال اجرا ندارد، اما برای اعمال تغییرات، باید سرویس sshd را مجدداً راه‌اندازی کرد:rc-service sshd restart
در صورت عدم امکان به‌روزرسانی فوری، توصیه می‌شود ورود با رمز عبور را غیرفعال کنید. این کار با تغییر تمام خطوط PasswordAuthentication در فایل /etc/ssh/sshd_config (شامل بلوک‌های Match) به PasswordAuthentication no انجام می‌شود. قبل از انجام این کار، اطمینان حاصل کنید که ورود با کلید SSH فعال است و اتصال فعلی خود را حفظ کنید تا زمانی که ورود با کلید با موفقیت آزمایش شود.
Alpine یک دستور برای اعمال تغییرات در فایل پیکربندی ارائه کرده است. پس از راه‌اندازی مجدد sshd، می‌توانید با دستور زیر از اعمال شدن صحیح تنظیمات اطمینان حاصل کنید:sshd -T | grep -i passwordauthentication
این دستور باید passwordauthentication no را برگرداند.
برای بررسی اینکه آیا سیستم شما مورد نفوذ قرار گرفته است یا خیر، لاگ‌های /var/log/messages را برای هرگونه ثبت “Accepted password” برای حساب‌های بدون رمز عبور (مانند alpine، root، یا حساب‌هایی که فقط از کلید استفاده می‌کنند) بررسی کنید. در صورت مشاهده چنین مواردی، فرض کنید سیستم شما مورد نفوذ قرار گرفته است.
اختلاف نظر بر سر مسئولیت
در توضیحات انتشار OpenSSH آمده است که علت اصلی مشکل خارج از sshd بوده و وصله 10.6p2 یک راه‌حل موقت است که با جلوگیری از پردازش فیلدهای رمز عبور کوتاه‌تر از ۴ کاراکتر، مشکل را برطرف می‌کند. در مقابل، Rich Felker، نویسنده musl، در اطلاعیه‌ای اعلام کرده است که این مشکل تقصیر musl نیست، بلکه نحوه استفاده فراخوان‌کننده (caller) نادرست بوده است. با این حال، Felker اضافه کرده است که این مکانیزم “مدت‌هاست که در دست بررسی برای تغییر است” و احتمالاً در چرخه انتشار بعدی تغییر خواهد کرد.
ارزیابی ریسک و وضعیت بهره‌برداری
امتیاز CVSS 3.1 در NVD برای این آسیب‌پذیری 8.1 (ریسک بالا، پیچیدگی حمله بالا) تعیین شده است. آژانس امنیت سایبری و زیرساخت آمریکا (CISA) وضعیت بهره‌برداری از این آسیب‌پذیری را “اثبات مفهوم موجود” ارزیابی کرده است، به این معنی که هنوز به طور فعال مورد سوءاستفاده قرار نگرفته است. با این حال، در روز انتشار عمومی، مخزن GitHub Kültekin حاوی محیط بازسازی و اثبات مفهوم (PoC) شده بود و دو محیط بازسازی دیگر نیز در GitHub منتشر شدند. اسکنر متن‌باز Google به نام goonami-scanner نیز در همان روز قابلیت شناسایی این آسیب‌پذیری را اضافه کرد.
