Korzystacie z OpenSSH na hostach z musl libc? Lepiej patchujcie i wyłączcie PasswordAuthentication

5 listopada 2026 r. ukazała się łatka do Portable OpenSSH (dla przypominienia nie chodzi o bezinstalacyjną wersję serwera, która często wykorzystuje suffix “portable”, w przypadku OpenSSH chodzi o możliwość przenoszenia między systemami). Wydanie zawiera mitygację (workaround) na krytyczną podatność, która pozwala ominąć uwierzytelnianie hasłem na serwerach Linux z biblioteką musl libc i wyłączonym PAM (sprawdzenie hasła odbywa się z wykorzystaniem biblioteki libc – np. implementacji musl). Damien Miller z zespołu OpenSSH apeluje wprost: jeśli macie takie systemy (przykładem są lekkie kontenery z Alpine Linux), natychmiast ustawcie PasswordAuthentication=no albo wyłączcie na nich SSH.

Błąd nie w sshd, ale sshd jest drogą ataku

Zespół OpenSSH podkreśla, że źródło problemu leży poza sshd. Mimo to podatność da się wykorzystać właśnie przez daemona bezpiecznej zdalnej powłoki, dlatego tam wprowadzono obejście. Najbardziej prawdopodobny scenatiusz to podatność w bibliotece musl lub sposób weryfikacji haseł bez PAM, jednak autorzy oficjalnie nie wskazali komponentu. Szczegóły techniczne nie zostały na razie ujawnione.

Według notatek dołączonych do wydania, skutki wykorzystania podatności są bardzo niebezpieczne – obejście uwierzytelniania hasłem (password authentication bypass). Zadalny atakujący z dostępem do SSH, może więc zalogować się na konto bez podania poprawnego hasła. Jeśli dopuszczone jest logowanie na roota hasłem, oznacza to pełne przejęcie systemu. Nie podano, czy do ataku potrzebna jest znajomość nazwy użytkownika ani jakie są dodatkowe ograniczenia. Zespół OpenSSH sklasyfikował problem jako krytyczny.

Podatna konfiguracja

Na szczęście nie jest to bomba nuklearna – atak jest możliwy, gdy jednocześnie spełnione są wszystkie warunki:

• system Linux z biblioteką musl libc (np. OpenWRT – chociaż tam domyślnym daemonem SSH jest Dropbear),
• sshd zbudowany bez obsługi PAM albo zbudowany z PAM, ale uruchomiony z UsePAM=no (Miller potwierdził, że ta konfiguracja również jest podatna),
• włączone PasswordAuthentication,
• OpenSSH starszy niż 10.6p2.

Podatność nie występuje na systemach innych niż Linux, na Linuksach z glibc ani tam, gdzie hasła weryfikuje PAM. Najbardziej narażony jest Alpine Linux, którego domyślny pakiet openssh-server nie korzysta z PAM. Dotyczy to także kontenerów zbudowanych na obrazach alpine z uruchomionym sshd. Warto sprawdzić również inne dystrybucje oparte na musl: postmarketOS, Void Linux (wariant musl), Chimera Linux, Adélie Linux, profile musl w Gentoo oraz urządzenia z OpenWrt, jeśli zamiast Dropbeara działa na nich OpenSSH. Na tę chwile nie ma informacji o alternatywnych implementacjach serwerów SSH.

Podatność zgłosił Özgün Kültekin z firmy Wakefield (wakefield.co). Zespół OpenSSH dowiedział się o problemie dzień przed publikacją poprawki, a deweloperzy Alpine Linux przygotowali zaktualizowany pakiet równie szybko. Tak krótki czas reakcji jest celowy. Miller tłumaczy, że agenty AI coraz częściej odkrywają te same błędy ponownie, nieraz w ciągu kilku godzin. Dlatego zespół uważa długie embarga za praktykę, która głównie pomaga atakującym. Chociaż niektórzy twierdzą, że responsible disclosure jest martwe od lat 90 :)

1. Aktualizacja OpenSSH do wersji 10.6p2. W Alpine wystarczy apk upgrade openssh; obrazy kontenerów trzeba przebudować.
2. Jeśli aktualizacja nie jest od razu możliwa, należy ustawić w sshd_config opcję PasswordAuthentication no (sprawdzić także bloki Match) i przeładować sshd (!!!). Ewentualnie wyłączyć SSH.
3. Ograniczyć dostęp do SSH na firewallu do zaufanych adresów.
4. Przejrzeć logi logowań ssh z nieznanych adresów przy pomocy hasła.

Szybki test, czy host jest podatny:

ldd $(command -v sshd) | grep -E 'musl|libpam'
sshd -T | grep -iE '^(passwordauthentication|usepam)'
ssh -V

Narażony jest host, na którym jednocześnie: binarka korzysta z ld-musl, PAM jest nieobecny lub usepam no, passwordauthentication yes, a wersja jest starsza niż 10.6p2.

~blh

Aktualizacja:
Jeśli to się potwierdzi, to zabawnie: https://sshhole.com/