Luka OpenSSH z musl: poprawka i pakiety Alpine

5 listopada 2026 r. projekt OpenSSH wydał wersję 10.6p2 z poprawką dla luki umożliwiającej obejście uwierzytelniania hasłem w określonych konfiguracjach OpenSSH z biblioteką musl. Administratorzy Alpine powinni sprawdzić, czy ich serwer spełnia opisane warunki, zainstalować poprawioną rewizję pakietu dla swojej gałęzi i ponownie uruchomić sshd. Informacja o wydaniu OpenSSH 10.6p2

Po aktualizacji pakietu uruchom ponownie sshd: dopiero wtedy działający serwer zacznie korzystać z poprawionej wersji.

Kiedy konfiguracja Alpine spełnia warunki luki

Według komunikatu Alpine wszystkie opisane warunki muszą wystąpić jednocześnie: serwer OpenSSH działa na musl, PAM jest wyłączone (na przykład przez UsePAM no), a PasswordAuthentication ma wartość yes. Konto, na które może zalogować się atakujący, musi mieć w polu hasła znak *; na maszynie musi też istnieć co najmniej jedno inne konto lokalne z hashem zaczynającym się od $5$ lub $6$.

W takiej konfiguracji hasło o długości od 257 do 1 024 bajtów może doprowadzić do obejścia uwierzytelniania. Alpine podaje, że wystarczy jedno połączenie SSH, bez ponawiania prób. Samo konto oznaczone kluczem jako bezhasłowe nie przesądza o podatności: znaczenie ma również ustawienie uwierzytelniania hasłem na serwerze.

Alpine wskazuje, że luka nie dotyczy konfiguracji z PasswordAuthentication no, OpenSSH korzystającego z PAM przy UsePAM yes, kont z ! w polu hasła ani kontenerów, w których nie działa sshd. W komunikacie musl wykluczono także Dropbear, czyli serwer SSH inny niż OpenSSH.

Poprawione rewizje pakietu Alpine i restart sshd

Alpine podało poprawione rewizje pakietu openssh-server dla gałęzi od 3.16 do 3.24 oraz dla edge:

Po aktualizacji Alpine zaleca ponownie uruchomić usługę:

apk upgrade -U -a
rc-service sshd restart

Aktualizacja pakietu sama nie zastępuje procesu sshd, który już działa. Jeśli administrator nie może zainstalować poprawki, Alpine zaleca wyłączyć uwierzytelnianie hasłem, ustawiając PasswordAuthentication no, i zrestartować usługę.

OpenSSH wskazuje, że źródło problemu znajduje się poza sshd, choć obejście wprowadzono właśnie w tym serwerze. Rich Felker, autor musl, opisał problem jako nieprawidłowe użycie biblioteki przez program wywołujący. Stanowisko Felkera w komunikacie musl

Kiedy wskazane obrazy Alpine tiny-cloud mogą być narażone

Oficjalne obrazy tiny-cloud Alpine w wersjach od 3.18.11 do 3.24.3, w wariantach qcow2, VHD i AMI, zawierają konto alpine z * w polu hasła oraz bezhasłowym doas. Według Alpine są bezpieczne przy pierwszym uruchomieniu. Warunki podatności mogą pojawić się później, gdy na maszynie istnieje hash $6$ i jednocześnie spełnione są pozostałe wymagania dotyczące serwera i uwierzytelniania. Po zalogowaniu na konto alpine napastnik może użyć doas, by uzyskać uprawnienia roota.

Alpine zaleca sprawdzenie /var/log/messages pod kątem wpisów Accepted password dla kont, które nie powinny mieć hasła, oraz przejrzenie konfiguracji doas, kont użytkowników, plików i kluczy authorized_keys.