Ta luka brzmi jak żart. Wystarczy za długie hasło

Konto ma zablokowane logowanie hasłem? W określonych systemach z OpenSSH wystarczyło podać hasło absurdalnie długie. Błąd przetrwał około dekady i może dotyczyć m.in. Alpine Linux oraz OpenWrt.

Nowo ujawniony błąd na styku OpenSSH i biblioteki musl powodował, że w ściśle określonych konfiguracjach można było zalogować się hasłem na konto, które w ogóle nie powinno przyjmować żadnego hasła. Wystarczyło, że podany ciąg miał więcej niż 256 znaków. Badacz bezpieczeństwa Ozgun Kultekin, który opisał podatność i nadał jej wymowną nazwę „*sshole”, twierdzi, że problem w tej postaci mógł istnieć od 2016 r.

Czytaj też:

Nie oznacza to na szczęście magicznego klucza pasującego do każdego serwera z Linuksem. Podatny jest stosunkowo specyficzny zestaw konfiguracji związany przede wszystkim z systemami wykorzystującymi bibliotekę musl, takimi jak Alpine Linux, OpenWrt, Buildroot czy Yocto. Debian, Ubuntu i Fedora korzystające z glibc nie są podatne na opisany atak, podobnie jak konfiguracje przeprowadzające uwierzytelnianie przez PAM.

Tyle że „stosunkowo specyficzny” w świecie Linuksa nie musi oznaczać „nieistotny”. Alpine jest doskonale znany administratorom, użytkownikom kontenerów i chmurowych maszyn wirtualnych, a OpenWrt siedzi o wiele bliżej zwykłego użytkownika, bo jest popularnym systemem dla routerów i innych urządzeń sieciowych.

Żeby zrozumieć ten błąd, trzeba najpierw zejść o warstwę niżej niż samo SSH. W uniksowych systemach informacje niezbędne do weryfikacji haseł są przechowywane m.in. w pliku /etc/shadow. Jeżeli zamiast prawidłowego skrótu hasła w odpowiednim polu znajduje się znak *, to ma to praktycznie oznaczać konto, na które nie da się uwierzytelnić zwykłym hasłem. Gwiazdka nie jest bowiem prawidłowym skrótem hasła.

To bardzo stary mechanizm. Kultekin prześledził historię takiego rozwiązania aż do BSD z 1980 r., gdzie konto daemon miało właśnie * w miejscu przeznaczonym na hasło. Zamysł jest banalny: skoro żadne wpisane przez człowieka hasło nie może wygenerować takiego skrótu, to żadne nie powinno zostać zaakceptowane. I przez długie lata takie rozumowanie miało sens.

Problem powstał dlatego, że kilka całkiem rozsądnych decyzji projektowych podjętych w różnych miejscach i różnych latach zaczęło na siebie nachodzić. Każda miała rozwiązać konkretny problem. Razem stworzyły coś zdecydowanie mniej rozsądnego.

Jednym z bohaterów tej historii jest crypt(), czyli funkcja wykorzystywana do obsługi skrótów haseł. Jak opisuje Kultekin, specyfikacja przewidywała, że kiedy crypt() nie może wykonać operacji, to funkcja zwraca NULL. Miało to jednak praktyczny minus: program, który nie sprawdził poprawnie wyniku przed jego użyciem, mógł się wysypać. Twórcy musl w 2012 r. zmienili więc zachowanie funkcji. Zamiast NULL, przy błędzie crypt() zaczął zwracać wartość, która nie powinna być prawidłowym hashem hasła. Wybrano *.

I właśnie tutaj zapala się pierwsza lampka ostrzegawcza, bo dokładnie ten sam symbol był już wykorzystywany jako wartość oznaczająca konto, dla którego logowanie hasłem ma być niemożliwe. To jeszcze samo w sobie nie wystarczało do przeprowadzenia ataku. Kolejny element układanki również pojawił się w 2012 r. Musl wprowadził obsługę SHA-512 crypt, ograniczając długość hasła do 256 bajtów. Kultekin wskazuje, że ograniczenie miało chronić przed problemem rosnącego kosztu obliczeń dla wyjątkowo długich danych wejściowych. Przy przekroczeniu limitu operacja kończyła się błędem. A kiedy operacja kończyła się błędem, musl zwracał wspomniane *.

Mamy więc już dwa puzzle: konto z zablokowanym hasłem ma zapisane *, a nieudane obliczenie skrótu w musl też może dać *. Brakuje jeszcze OpenSSH.

W 2016 r. OpenSSH mierzył się z CVE-2016-6210, czyli podatnością umożliwiającą ustalanie istniejących nazw użytkowników dzięki różnicom w czasie odpowiedzi serwera. Problem był całkiem logiczny. Dla istniejącego użytkownika serwer musiał wykonać kosztowniejszą operację dotyczącą hasła. Dla użytkownika, który nie istniał, nie było czego sprawdzać. Odpowiedzi można było więc mierzyć, a na podstawie różnic wyciągać informacje o kontach znajdujących się w systemie.

Poprawka miała zatrzeć tę różnicę. OpenSSH zaczął wykonywać kosztowną operację również wtedy, gdy brakowało użytecznego skrótu hasła. Według opisu błędu mechanizm obejmował także prawdziwe konta, dla których w polu hasła widniało *. I oto mamy komplet.

OpenSSH próbuje wykonać operację dla konta z *. Musl dostaje przesadnie długie hasło, więc crypt() nie jest w stanie normalnie go obsłużyć. W wyniku błędu zwraca *. Następuje porównanie z wartością zapisaną dla konta, która również wynosi *. Gwiazdka równa się gwiazdce. Użytkownik zostaje wpuszczony.

Trudno o lepszy przykład tego, że w bezpieczeństwie kilka mechanizmów działających zgodnie ze swoim projektem może razem stworzyć katastrofalny efekt uboczny.

Tu warto bardzo mocno zaciągnąć hamulec, bo nagłówek o OpenSSH i „dowolnym haśle” aż prosi się o katastroficzną interpretację. Atak wymaga spełnienia kilku warunków jednocześnie. Serwer OpenSSH musi działać w środowisku wykorzystującym musl, takim jak Alpine Linux, OpenWrt, Buildroot lub Yocto. Uwierzytelnianie PAM musi być wyłączone, musi być włączone logowanie SSH za pomocą haseł, w systemie musi znajdować się konto z * jako wartością hasła oraz inne konto z prawidłowym hashem hasła. Badacz podaje bardziej precyzyjny zakres: w spełniającej te warunki konfiguracji konto z * przyjmowało ciąg o długości od 257 do 1024 znaków.

Luka nie pozwala na ominięcie normalnego, prawidłowo ustawionego hasła istniejącego konta. Nie mamy więc sytuacji, w której ktoś patrzy na serwer Alpine, wpisuje 300 razy literę A i automatycznie przejmuje dowolnego użytkownika. Problem dotyczy kont oznaczonych w sposób, który miał właśnie uniemożliwiać logowanie hasłem. Ten paradoks czyni całą historię tak interesującą: problemem nie jest słabe hasło a hasło w miejscu, w którym żadnego hasła nie powinno być.

W przeciętnej instalacji Ubuntu na domowym komputerze nie ma więc powodów do paniki. BleepingComputer zwraca uwagę, że systemy oparte na glibc, w tym Debian, Ubuntu i Fedora, nie są podatne na ten konkretny mechanizm. To samo dotyczy systemów korzystających przy uwierzytelnianiu z PAM. Znacznie ciekawsza jest sytuacja Alpine Linux. To lekka dystrybucja chętnie wykorzystywana w środowiskach serwerowych i kontenerowych, właśnie między innymi dzięki musl.

Według Kultekkina oficjalne obrazy Alpine dla AWS i Azure zawierają dotknięte problemem domyślne konto alpine. Badacz wskazuje przy tym, że ma ono możliwość korzystania z doas bez hasła, więc uzyskanie dostępu do takiego konta może w konsekwencji prowadzić do zdobycia uprawnień roota. To zasadniczo zmienia ciężar gatunkowy błędu.

Nie rozmawiamy już bowiem o osobliwości, którą da się odtworzyć na pieczołowicie spreparowanej maszynie laboratoryjnej. Według autora odkrycia podatna konfiguracja występuje w oficjalnych obrazach systemu przeznaczonych do uruchamiania w dwóch największych ekosystemach chmurowych.

Lista systemów wykorzystujących musl obejmuje ponadto OpenWrt, Buildroot oraz Yocto. Tego typu oprogramowanie spotyka się w świecie routerów i systemów wbudowanych, więc sprawa wychodzi poza klasyczne rozumienie „serwera z Linuksem”.

Musl przestał zwracać NULL w omawianej sytuacji w 2012 r., a w tym samym roku pojawiło się opisane ograniczenie dla bardzo długich haseł. Element po stronie OpenSSH wszedł do gry przy okazji poprawki CVE-2016-6210. Kultekin datuje więc istnienie podatnego połączenia na 2016 r. To około dekady.

Po drodze pojawiały się sygnały znajdujące się niebezpiecznie blisko sedna problemu. Autor odkrycia przytacza chociażby dyskusję na liście mailingowej musl z grudnia 2024 r. dotyczącą problemów BusyBox passwd z hasłem o długości 257 znaków. Występował tam ten sam limit oraz *, ale dyskusja nie została połączona z sshd.

Jeszcze ciekawiej robi się pod sam koniec tej historii. Kultekin wskazuje zmianę OpenSSH z 30 października 2026 r. będącą efektem przeglądu bezpieczeństwa. Jak twierdzi, kod odpowiadający za opisywany później błąd znajdował się zaledwie kilka linii dalej. Czasem różnica pomiędzy „wszystko jest w porządku” a „mamy dziesięcioletnią lukę” naprawdę mieści się na jednym ekranie edytora.

Kultekin twierdzi, że podczas poszukiwań wykorzystał agentów AI. Nie chodzi jednak o efektowną opowieść w rodzaju „sztuczna inteligencja spojrzała na OpenSSH i znalazła lukę, której ludzie nie widzieli przez dekadę”. Z jego relacji wynika znacznie bardziej przyziemny i zarazem ciekawszy sposób wykorzystania automatyzacji.

Badacz przygotowywał różne kompilacje sshd, uwzględniając między innymi glibc, musl, konfiguracje z PAM i bez PAM oraz warianty związane z shadow, a następnie poddawał je nietypowym próbom logowania. Łącznie przeprowadzono około 17 600 testów uwierzytelniania obejmujących m.in. nietypowe hashe, uszkodzone konfiguracje kont i przesadnie długie hasła. Jedna kombinacja zaczęła zachowywać się inaczej od pozostałych: musl bez PAM.

I to jest chyba ciekawszy przykład wykorzystania AI w cyberbezpieczeństwie niż kolejny chatbot dopisany do panelu administracyjnego. Maszyny świetnie nadają się do wykonywania tysięcy nudnych, systematycznie zmienianych eksperymentów, podczas gdy człowiek może skoncentrować się na pytaniu, dlaczego jeden wynik wygląda inaczej.

Dobra wiadomość jest taka, że administratorzy nie muszą czekać. Problem został poprawiony w OpenSSH 10.6p2. Administratorom Alpine Linux zalecana jest aktualizacja pakietów OpenSSH. Jako zabezpieczenie dla systemów, których nie można od razu zaktualizować, wskazywane jest wyłączenie uwierzytelniania SSH hasłem.

Jednocześnie należy pamiętać, że samo posiadanie OpenSSH nie oznacza podatności. Jeżeli serwer korzysta z glibc albo uwierzytelnianie przechodzi przez PAM, opisywany mechanizm ataku nie działa. To ważne, bo przy podatnościach dotyczących fundamentalnych narzędzi linuksowego świata bardzo łatwo przejść od technicznego opisu do komunikatu „wszyscy aktualizujcie wszystko natychmiast”. Tutaj zakres jest znacznie węższy.

„*sshole” jest niemal podręcznikowym przykładem problemu, którego nie da się sensownie opowiedzieć zdaniem „programista popełnił głupi błąd”. Musl chciał uniknąć problemów wynikających z NULL. OpenSSH chciał utrudnić rozpoznawanie istniejących użytkowników poprzez analizę czasu odpowiedzi. Administrator umieszczający * w /etc/shadow chciał wyłączyć możliwość logowania hasłem. Każdy z tych mechanizmów miał swoje uzasadnienie. Dopiero połączenie ich ze sobą stworzyło problem.

I to jest chyba najciekawsza lekcja z całej historii. Bezpieczeństwo dużych systemów rzadko sprowadza się wyłącznie do sprawdzenia, czy pojedyncza funkcja jest napisana prawidłowo. OpenSSH może zachowywać się sensownie. Musl może zachowywać się zgodnie ze swoim projektem. Stary uniksowy mechanizm blokowania haseł może działać od dekad. A później zestawia się te trzy rzeczy razem i okazuje się, że gwiazdka, która przez lata miała mówić serwerowi „żadne hasło”  w pewnych warunkach zaczyna znaczyć „wpuść go”.