256-аас урт дурын нууц үгээр шууд Root эрх авна: Alpine Linux ба OpenSSH-ийн 10 жилийн түүхтэй "*sshole" цоорхой

Сүлжээ, серверийн аюулгүй байдлын тулгуур багана болсон OpenSSH дээр хамгаалалтыг бүрэн тойрч гардаг маш хачирхалтай бөгөөд аюултай эмзэг байдал илэрлээ. CVE-2026-123158 дугаараар бүртгэгдэж, нээсэн судлаач нь *"sshole" (эсвэл sshhole) хэмээн нэрийдсэн энэхүү цоорхой нь Alpine Linux болон бусад musl libc ашигладаг системүүдэд шууд нөлөөлж байна.

Хамгийн ноцтой нь, халдагч системийн бодит нууц үгийг мэдэх, эсвэл brute-force хийх ямар ч шаардлагагүй. Зөвхөн 257-оос 1024 тэмдэгттэй дурын текстийг нууц үг болгон илгээхэд л систем түүнийг "зөв нууц үг" гэж таньж нэвтрүүлж байна.

Алдаа хэрхэн ажилладаг вэ? Хоёр стандартын үхлийн мөргөлдөөн

Энэхүү алдаа нь OpenSSH-ийн криптограф алгоритмд биш, харин OpenSSH болон Си хэлний стандарт сан болох musl libc-ийн харилцан ажиллагааны логикт 2016 оноос хойш 10 жилийн турш нуугдаж байжээ.

Механизмыг нарийвчлан авч үзвэл:

/etc/shadow ба одон тэмдэг (*): Юникс төст системүүдэд нууц үг тохируулаагүй, эсвэл зөвхөн SSH түлхүүрээр (key-only) нэвтрэх зориулалттай хэрэглэгчийн нууц үгийн хэш талбарт /etc/shadow дотор * (одон тэмдэг) бичигддэг. Энэ нь уг данс нууц үгээр хэзээ ч нэвтрэх ёсгүйг илтгэдэг уламжлалт тэмдэглэгээ юм.
musl libc-ийн crypt() функцийн онцлог: Линукс системүүдийн түгээмэл хэрэглэдэг glibc санд нууц үг шалгах явцад алдаа гарвал функц NULL утга буцаадаг бөгөөд OpenSSH үүнийг шууд татгалздаг. Гэтэл хөнгөн жинтэй musl libc-ийн crypt() функц (ялангуяа SHA-256, SHA-512 хэш тооцоололд) 256 байтаас урт нууц үг өгөгдөх үед алдаа зааж, буцаах утгадаа тусгайлан ганц * тэмдэгт бүхий стрингийг буцаадаг аж!
OpenSSH-ийн логик харьцуулалт: Alpine Linux-ийн анхдагч openssh-server нь PAM (Pluggable Authentication Modules)-гүйгээр ажилладаг. SSH клиентээс 257+ тэмдэгттэй текст ирэх үед sshd нь нууц үгийг crypt() руу дамжуулна. musl алдаа заан * буцаана. Харин OpenSSH-ийн баталгаажуулах код нь musl-ийн буцаасан *-ийг /etc/shadow файл дахь нууц үггүй хэрэглэгчийн * утгатай харьцуулна (strcmp("*", "*") == 0). Хоёр тэмдэгт төгс тохирсон тул OpenSSH халдагчийг "нууц үгээ зөв орууллаа" хэмээн систем рүүгээ найрсаг урьж оруулдаг байна!

Хэн эрсдэлд орсон бэ?

Хэрэв таны систем дараах 4 нөхцөлийг зэрэг хангаж байвал та шууд халдлагад өртөх эрсдэлтэй:

musl libc ашигладаг системтэй: Үүнд container болон cloud орчинд өргөн хэрэглэгддэг Alpine Linux, чиглүүлэгч төхөөрөмжүүдийн OpenWrt, Buildroot, Yocto орно. Ubuntu, Debian, RedHat зэрэг glibc ашигладаг системүүд өртөхгүй.
PAM модулгүй OpenSSH ажиллаж байгаа: Alpine Linux-ийн стандарт openssh-server багц нь үндсэн тохиргоогоороо PAM-гүй байдаг.
PasswordAuthentication тохиргоо асаалттай (yes): OpenSSH-ийн үндсэн тохиргоо нь нууц үгээр нэвтрэхийг зөвшөөрсөн байдаг.
Системд нууц үг нь * гэж тохируулагдсан хэрэглэгч байгаа: Үүнд зөвхөн SSH key-ээр нэвтрэхээр үүсгэсэн дансууд багтана. Жишээ нь AWS, Azure зэрэг үүлэн систем дээрх албан ёсны Alpine cloud image-ийн үндсэн alpine хэрэглэгч нь нууц үггүй байдаг төдийгүй нууц үг нэхэхгүйгээр doas (sudo-той адил) эрх авах боломжтой байдаг. Энэ нь халдагч хэдхэн хормын дотор серверийн Root эрхийг бүрэн авна гэсэн үг юм.

Root хэрэглэгчийн хувьд PermitRootLogin prohibit-password тохиргоотой байвал шууд нэвтрэхгүй ч, дурын энгийн дансаар нэвтрэн давуу эрхээ ахиулах (privilege escalation) өндөр эрсдэлтэй.

Хэрхэн шалгаж, аюулгүй болгох вэ?

OpenSSH баг 2026 оны 11-р сарын 5-нд яаралтай Portable OpenSSH 10.6p2 хувилбарыг гаргаж, /etc/shadow доторх 4-өөс цөөн тэмдэгттэй хэшийг автоматаар хүчингүйд тооцдог болголоо. Мөн Alpine Linux бүх дэмжигдэж буй хувилбарууддаа (3.16-аас 3.24 болон edge) засварыг хүргэсэн байна.

1. Яаралтай шинэчлэх (Update):

Alpine систем дээрээ openssh багцаа шинэчилж, сервисийг заавал дахин ачаална уу (багц шинэчилснээр ажиллаж буй процесс шинэчлэгдэхгүй):

apk update
apk upgrade openssh
rc-service sshd restart

2. Түр зуурын хамгаалалт (Шинэчлэх боломжгүй бол):

Хэрэв багцаа шууд шинэчлэх боломжгүй бол SSH дээр нууц үгээр нэвтрэх тохиргоог бүрэн хаах шаардлагатай:

echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
rc-service sshd restart

(Жич: Өөрийн SSH Public Key зөв тохируулагдсан эсэхийг шалгаж байж хийнэ үү, эс бөгөөс серверээсээ түгжигдэж болзошгүй).

3. Эрсдэлд орсноо шалгах:

Системийнauth лог (/var/log/messages эсвэл syslog) дээрээ нууц үг тохируулаагүй хэрэглэгч Accepted password for ... гэсэн төлөвтэй нэвтэрсэн мөр байгаа эсэхийг яаралтай шалгаарай. Хэрэв тийм бичиглэл байвал уг сервер аль хэдийн халдлагад өртсөн байх магадлалтай.

Инженерүүдийн хувьд энэ цоорхой нь C хэлний сангуудын алдааны код буцаах стандарт болон дээд түвшний системийн хүлээлт хоорондоо зөрөхөд аюулгүй байдлын хамгийн бат бөх системүүд ч ямар эмзэг болдгийг тод харуулсан сургамж боллоо.

Эх сурвалж:

*sshole аюулгүй байдлын судалгаа, Özgün Kültekin (Wakefield): https://sshhole.com/
Alpine Linux Security Advisory (CVE-2026-123158): https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/
Portable OpenSSH 10.6p2 хувилбарын мэдээлэл: https://www.openssh.org/releasenotes.html