Krytyczna poprawka OpenSSH eliminuje obejście uwierzytelniania haseł na Alpine Linux

Wprowadzenie do problemu / definicja

OpenSSH opublikował awaryjną poprawkę usuwającą krytyczny błąd, który w określonych warunkach umożliwiał obejście uwierzytelniania SSH na systemach korzystających z musl libc, przede wszystkim Alpine Linux. Problem dotyczył serwerów sshd działających bez PAM i mógł pozwolić na zalogowanie się do kont, które formalnie nie powinny akceptować logowania hasłem.

To szczególnie istotne w środowiskach, gdzie administratorzy zakładają, że konto oznaczone jako przeznaczone wyłącznie do logowania kluczem SSH pozostaje odporne na próby użycia hasła. W praktyce luka podważała to założenie i otwierała drogę do nieautoryzowanego dostępu z sieci.

W skrócie

Podatność została zaadresowana w wydaniu OpenSSH 10.6p2. Mechanizm ataku działał w sytuacji, gdy sshd samodzielnie weryfikował hasła bez udziału PAM, uwierzytelnianie hasłem było aktywne, a w systemie współistniały konta z klasycznym hashem hasła oraz konta oznaczone w sposób uniemożliwiający standardowo logowanie hasłem.

najsilniej narażone były systemy oparte o musl libc, zwłaszcza Alpine Linux,
atak wymagał jedynie dostępu sieciowego do SSH, nazwy użytkownika i bardzo długiego hasła,
problem dotyczył konfiguracji bez PAM, przy włączonym PasswordAuthentication,
luka mogła naruszać model bezpieczeństwa kont uznawanych za „key-only”.

Kontekst / historia

Źródło problemu nie sprowadzało się do jednego prostego błędu, lecz do połączenia kilku historycznych decyzji projektowych. W systemach Unix i Linux konta, które nie powinny przyjmować logowania hasłem, często mają w polu hasła specjalny znak, najczęściej *. Taki wpis nie reprezentuje prawidłowego hasha i ma skutecznie blokować logowanie hasłem.

Z czasem implementacja funkcji crypt() w musl libc została zmodyfikowana tak, aby przy błędzie zwracała specjalny ciąg znaków zamiast wartości pustej. Dodatkowo dla wybranych schematów haszowania, takich jak SHA-256 i SHA-512, wprowadzono ograniczenie długości hasła do 256 bajtów.

Równolegle OpenSSH już wcześniej wdrożył mechanizm wyrównywania czasu odpowiedzi dla nieistniejących lub specjalnie oznaczonych kont, aby utrudnić ataki bocznokanałowe. Każda z tych decyzji osobno miała sens z perspektywy bezpieczeństwa, ale ich połączenie na platformach z musl stworzyło nieprzewidziany scenariusz obejścia kontroli dostępu.

Analiza techniczna

W trybie bez PAM demon sshd sam przeprowadza weryfikację hasła. Pobiera zapisany wpis z systemu, wywołuje funkcję crypt() z odpowiednią solą, a następnie porównuje wynik z wartością przechowywaną dla danego użytkownika.

Problem ujawniał się, gdy konto docelowe miało w polu hasła pojedynczy znak *, czyli logicznie brak hasła. Ponieważ taki wpis nie zawiera pełnych danych potrzebnych do klasycznego haszowania, sshd korzystał z mechanizmu wyrównania czasu odpowiedzi i zapożyczał sól z innego konta posiadającego rzeczywisty hash hasła.

Na systemach z musl libc wywołanie crypt() dla hasła dłuższego niż 256 bajtów mogło zwrócić wartość *, sygnalizując niepowodzenie operacji. Jeżeli konto docelowe również miało w polu hasła znak *, porównanie kończyło się błędnym dopasowaniem, a logowanie zostawało zaakceptowane.

system musiał używać musl libc,
ścieżka uwierzytelniania SSH nie mogła wykorzystywać PAM,
PasswordAuthentication musiało pozostać włączone,
konto docelowe musiało mieć wpis * w polu hasła,
w systemie musiało istnieć co najmniej jedno inne konto z klasycznym hashem umożliwiającym zapożyczenie soli.

OpenSSH 10.6p2 wprowadza zabezpieczenie po stronie sshd, które odrzuca dopasowanie, gdy przechowywane pole hasła jest zbyt krótkie, aby mogło być prawidłowym hashem. To praktycznie blokuje możliwość wykorzystania tej ścieżki ataku przez SSH.

Konsekwencje / ryzyko

Z perspektywy operacyjnej luka jest bardzo poważna, ponieważ uderza w konta często uznawane za bezpieczne wyłącznie dzięki ograniczeniu do logowania kluczem. W środowiskach Alpine Linux mogą to być użytkownicy tworzeni bez hasła, konta pochodzące z usług katalogowych lub konta domyślne występujące w niektórych obrazach chmurowych.

Ryzyko gwałtownie rośnie, jeśli przejęte konto ma możliwość eskalacji uprawnień, na przykład przez doas, sudo albo inne lokalne mechanizmy administracyjne. W takim scenariuszu pojedyncze logowanie przez SSH może szybko doprowadzić do pełnego przejęcia hosta, zmiany konfiguracji lub utrwalenia dostępu.

Podatność ma szczególne znaczenie dla serwerów internetowych, środowisk kontenerowych z uruchomionym sshd, lekkich dystrybucji stosowanych w chmurze oraz systemów embedded opartych o musl. Nawet jeśli nie ma potwierdzenia powszechnego wykorzystania luki, prostota warunków ataku znacząco podnosi jej wartość z punktu widzenia operatorów ofensywnych.

Rekomendacje

Najważniejszym krokiem powinno być natychmiastowe zaktualizowanie OpenSSH do wersji zawierającej poprawkę oraz zrestartowanie usługi sshd. Sama instalacja nowego pakietu nie zawsze oznacza automatyczne przeładowanie działającego procesu.

wyłączyć PasswordAuthentication, jeśli środowisko korzysta wyłącznie z kluczy SSH,
sprawdzić, czy UsePAM jest aktywne tam, gdzie platforma to wspiera,
przejrzeć konta z wpisem * w /etc/shadow,
zweryfikować obecność kont z hashami aktywującymi podatną ścieżkę,
przeanalizować logi pod kątem wpisów typu Accepted password for dla kont, które nie powinny przyjmować haseł,
skontrolować zmiany w authorized_keys, harmonogramach zadań i lokalnych mechanizmach eskalacji uprawnień,
sprawdzić obrazy bazowe oraz szablony provisioningowe w środowiskach chmurowych,
objąć monitoringiem także inne platformy wykorzystujące musl libc.

Jeśli organizacja nie potrafi jednoznacznie wykluczyć nieautoryzowanego logowania, sytuację należy potraktować jako potencjalne naruszenie bezpieczeństwa. W takim przypadku wskazana jest pełna analiza śladów, weryfikacja aktywności użytkowników i ocena możliwego utrwalenia dostępu przez napastnika.

Podsumowanie

Awaryjna poprawka OpenSSH 10.6p2 zamyka krytyczną lukę umożliwiającą obejście uwierzytelniania hasłem na wybranych systemach z musl libc, przede wszystkim Alpine Linux. Problem wynikał z niebezpiecznej interakcji pomiędzy zachowaniem sshd, funkcją crypt() w musl oraz praktyką oznaczania kont bez hasła znakiem *.

Dla administratorów oznacza to konieczność pilnej aktualizacji, przeglądu konfiguracji SSH i sprawdzenia, czy konta uznawane za dostępne wyłącznie z użyciem klucza rzeczywiście nie były narażone na logowanie hasłem. To kolejny przykład, że bezpieczeństwo procesu uwierzytelniania zależy nie tylko od samej aplikacji, ale również od biblioteki systemowej, sposobu kompilacji i domyślnych ustawień dystrybucji.