Idealny koszmar dla serwera z Linuksem to sytuacja, w której atakujący musi tylko dotrzeć do portu Secure Shell (SSH) serwera, wejść bez pukania i przejąć nad nim kontrolę. To właśnie przydarzyło się Alpine Linux, popularnemu lekkiemu serwerowemu Linuksowi. A żeby dolać oliwy do ognia, stało się to zaledwie kilka dni po tym, jak Alpine Linux uniknął kuli wielkości dziury bezpieczeństwa w swojej implementacji GitLaba.

Jak wyjaśnił inżynier bezpieczeństwa Gregory Bryant w swoim poście na LinkedIn: „Większość obejść uwierzytelniania wynika ze złożonych łańcuchów logiki, ale wczorajsza luka w OpenSSH w Alpine Linux (CVE-2026-123158) sprowadza się do jednego znaku: *.”

Jeśli używasz Alpine Linux (lub innej dystrybucji opartej na musl) z domyślnym pakietem openssh-server (bez Pluggable Authentication Modules, czyli PAM) i włączonym PasswordAuthentication, atakujący może zalogować się na konta z wyłączonym hasłem lub konta tylko z kluczem, po prostu wysyłając hasło o długości od 257 do 1024 bajtów.

Alpine Linux nie jest jedynym systemem operacyjnym korzystającym z musl, lekkiej wersji standardowej biblioteki C (libc). Inne systemy operacyjne używające musl i potencjalnie podatne to Adélie Linux; Void Linux; Sabotage Linux; OpenWrt, wariant Androida; oraz Yocto Project, używany do budowania wbudowanych dystrybucji Linuksa.

Wind River, producent komercyjnej wbudowanej dystrybucji Linuksa Wind River Linux, również bada tę kwestię. Przedstawiciel firmy powiedział mi: „Wind River poważnie traktuje bezpieczeństwo. Aktywnie analizujemy zgłoszoną lukę i oceniamy jej potencjalny wpływ. Podejmiemy odpowiednie działania w razie potrzeby.”

Za kulisami, gdy OpenSSH jest budowany bez PAM, weryfikuje hasła, haszując próbę hasła za pomocą funkcji crypt() z biblioteki C. Następnie porównuje wynik z przechowywanym polem hasła konta. Dotąd wszystko w porządku.

Ale gdy klucz jest dłuższy niż 256 bajtów, funkcja crypt() z musl zwraca ciąg * jako wskaźnik błędu. To samo znajduje się w polu hasła dla każdego konta bez hasła, na przykład konta tylko z kluczem. W ten sposób „hash” pasuje, logowanie się udaje, a atakujący wchodzi.

Aby to wykorzystać, atakujący potrzebuje jedynie nazwy takiego konta. Potrzebuje także co najmniej jednego innego konta na maszynie z hashem hasła 5 lub 6, a następnie wysłania hasła o długości od 257 do 1024 bajtów. Według Alpine wystarczy jeden użytkownik z hasłem, aby każde konto bez hasła stało się dostępne.

W systemach Linux korzystających z crypt() z glibc, czyli prawie wszystkich, ta sama próba zwróciłaby NULL przy błędzie, co sshd już odrzuca, więc Debian, Ubuntu, Fedora itp. nie są dotknięte.

Według *sshole, grupy, która odkryła problem, jest to efekt uboczny ukryty od 2016 roku.

Alpine podało, że każda sprawdzona wersja jest dotknięta: od 3.21 do 3.24, edge oraz starsze gałęzie od 3.16 do 3.20. Ekspozycja wymaga następujących warunków:

Root w większości przypadków nie jest bezpośrednio narażony. Jest dostarczany jako root:* w obrazie bazowym od około Alpine 3.16, ale domyślne PermitRootLogin prohibit-password w OpenSSH to blokuje. Inne konto, które może stać się rootem, na przykład przez doas, nadal daje atakującemu drogę do roota.

Alpine wyróżniło swoje oficjalne obrazy tiny-cloud, wersje od 3.18.11 do 3.24.3, jako szczególnie podatne. Są one dostarczane z użytkownikiem alpine z polem hasła * i bezhasłowym doas. Są bezpieczne przy pierwszym uruchomieniu, ale stają się podatne, gdy na maszynie istnieje jakikolwiek hash 6. Może się to zdarzyć, gdy administrator ustawi hasło konsoli lub gdy dane użytkownika dodadzą użytkownika z zahaszowanym hasłem, co oznacza w zasadzie wszystkie z nich.

Alpine wydało 3.21.10, 3.22.8, 3.23.8 i 3.24.4 w czwartek, z poprawką OpenSSH wśród zmian bezpieczeństwa. Opublikowało także poprawione pakiety dla każdej wersji od 3.16. Alpine 3.21 osiągnęło koniec wsparcia 1 listopada.

Właśnie wydane OpenSSH 10.6p2 unika problemu w sshd. Stabilne gałęzie Alpine zawierają poprawkę na ten sam problem. Należy uruchomić apk upgrade -U -a, a następnie zrestartować th