Wprowadzenie do problemu / definicja
W listopadzie 2026 roku ujawniono podatność CVE-2026-123158, nazwaną SSHole, która dotyczy serwera OpenSSH działającego na wybranych systemach Linux korzystających z biblioteki musl libc przy wyłączonym PAM. Błąd może umożliwić nieuwierzytelnionemu atakującemu zalogowanie się do kont, które formalnie nie powinny akceptować logowania hasłem, jeśli spełnione są określone warunki konfiguracyjne.
To istotny problem dla organizacji wykorzystujących lekkie dystrybucje i obrazy systemowe, zwłaszcza tam, gdzie SSH pozostaje podstawowym kanałem administracyjnym. Ryzyko rośnie, gdy podatne konto ma wysokie uprawnienia lub dostęp do wrażliwych zasobów.
W skrócie
SSHole pozwala obejść oczekiwane zabezpieczenie kont z wyłączonym hasłem w części środowisk opartych o musl. Mechanizm nadużycia opiera się na przesłaniu nadmiernie długiego hasła, co prowadzi do błędnego wyniku porównania podczas uwierzytelniania.
- Podatność dotyczy OpenSSH na Linuxie z musl libc i wyłączonym PAM.
- Najczęściej wskazywanym środowiskiem ryzyka są wdrożenia oparte na Alpine Linux.
- Ataki pojawiły się bardzo szybko po publicznym ujawnieniu problemu.
- Producent udostępnił poprawkę w wersji OpenSSH 10.6p2.
Kontekst / historia
Źródło podatności wynika z połączenia kilku historycznych decyzji implementacyjnych dotyczących obsługi haseł i logiki uwierzytelniania. W określonych warunkach serwer SSH wykonuje operację haszowania również dla kont, które nie powinny dopuszczać logowania hasłem.
W środowiskach korzystających z musl libc występuje specyficzne zachowanie przy błędzie przetwarzania zbyt długiego hasła. Jeżeli konto systemowe ma w polu hasła znak „*”, czyli historyczny znacznik braku możliwości logowania hasłem, błędny wynik funkcji kryptograficznej może zostać potraktowany jako zgodny z zapisanym stanem konta. W efekcie dochodzi do niezamierzonego uwierzytelnienia.
Znaczenie tej luki zwiększa popularność Alpine Linux i podobnych lekkich środowisk używanych w kontenerach, chmurze oraz wdrożeniach o ograniczonym narzucie systemowym. To sprawia, że problem ma realny wymiar operacyjny, mimo dość konkretnych warunków eksploatacji.
Analiza techniczna
SSHole nie oznacza możliwości zalogowania się do dowolnego użytkownika przy użyciu przypadkowego hasła. Skuteczne wykorzystanie wymaga konkretnej kombinacji czynników: systemu Linux z musl libc, OpenSSH bez integracji PAM oraz konta, którego wpis hasła odpowiada stanowi zablokowanemu poprzez znak „*”.
Przebieg ataku można opisać w kilku krokach. Napastnik inicjuje logowanie SSH do wybranego konta, a następnie zamiast poprawnego hasła przesyła bardzo długi ciąg znaków. W bibliotece musl próba obliczenia skrótu dla takiej wartości kończy się błędem. Błędny wynik koliduje semantycznie ze znacznikiem używanym do oznaczania kont bez aktywnego hasła, przez co serwer może uznać porównanie za poprawne i dopuścić logowanie.
Z opublikowanych analiz wynika, że praktyczny zakres długości hasła wykorzystywanego w ataku mieści się między 257 a 1024 bajtami. Jednocześnie luka nie pozwala ominąć prawidłowo ustawionych haseł użytkowników posiadających poprawne skróty w systemie. Nie dotyczy też środowisk opartych o glibc, systemów nielinuxowych ani konfiguracji, w których weryfikacja hasła odbywa się przez PAM.
Szczególnie niepokojący jest fakt, że po ujawnieniu problemu bardzo szybko zaobserwowano aktywność ofensywną. Opisywane przypadki obejmowały użycie nieinteraktywnych sesji SSH oraz podstawowe komendy rozpoznawcze, typowe dla początkowej fazy kompromitacji.
Konsekwencje / ryzyko
Wpływ podatności zależy przede wszystkim od uprawnień konta, które może zostać przejęte. Jeżeli narażone jest konto uprzywilejowane, skutkiem może być pełna kompromitacja hosta. W przypadku kont technicznych lub wdrożeniowych ryzyko obejmuje kradzież sekretów, poświadczeń aplikacyjnych i dalszy ruch boczny w infrastrukturze.
- nieautoryzowany dostęp do hostów wystawionych do internetu,
- przejęcie kont typu root lub kont serwisowych,
- dostęp do sekretów wdrożeniowych i kluczy SSH,
- utrwalenie dostępu przez modyfikację plików authorized_keys,
- zwiększenie wpływu na klastry, kontenery i środowiska chmurowe,
- zakłócenie ciągłości działania usług.
Szczególnie narażone mogą być środowiska DevOps, urządzenia embedded korzystające z musl oraz hosty, na których wyłączono PAM w celu uproszczenia konfiguracji. W takich przypadkach pozornie niski poziom złożoności wdrożenia może przełożyć się na podwyższone ryzyko bezpieczeństwa.
Rekomendacje
Najważniejszym krokiem jest niezwłoczne wdrożenie poprawionej wersji OpenSSH 10.6p2 lub pakietu dostarczonego przez producenta dystrybucji, a następnie restart usługi sshd. Sama instalacja aktualizacji bez przeładowania procesu może nie wystarczyć do usunięcia ryzyka w działającym środowisku.
- zidentyfikować systemy używające musl libc, zwłaszcza Alpine Linux i pochodne obrazy kontenerowe,
- sprawdzić, czy OpenSSH działa z wyłączonym PAM,
- przeanalizować konta posiadające w polu hasła znacznik „*”,
- przeszukać logi pod kątem zaakceptowanych logowań hasłem dla kont, które nie powinny ich przyjmować,
- zweryfikować historię użycia kont root, alpine oraz użytkowników przeznaczonych wyłącznie do logowania kluczem,
- skontrolować pliki authorized_keys, nowych użytkowników i nietypowe procesy lub połączenia wychodzące,
- ograniczyć ekspozycję SSH do zaufanych adresów przez ACL, VPN lub bastiony administracyjne,
- rozważyć wymuszenie PAM tam, gdzie jest to zgodne z modelem operacyjnym,
- wdrożyć detekcję prób logowania z nienaturalnie długimi hasłami.
Jeżeli istnieją przesłanki wskazujące na udane logowanie, system należy traktować jako potencjalnie skompromitowany. W takiej sytuacji konieczne są działania w trybie incident response, w tym zabezpieczenie artefaktów, rotacja poświadczeń, analiza trwałości dostępu i ocena wpływu na sąsiednie zasoby.
Podsumowanie
SSHole pokazuje, że krytyczne skutki mogą wynikać z nieoczywistej interakcji pomiędzy biblioteką systemową, logiką uwierzytelniania i historycznymi mechanizmami bezpieczeństwa. Mimo że warunki eksploatacji są zawężone, szybkie pojawienie się realnych prób ataku potwierdza praktyczne znaczenie tej luki.
Organizacje korzystające z OpenSSH na systemach opartych o musl powinny potraktować aktualizację jako działanie pilne. Równolegle warto przeprowadzić przegląd logów, konfiguracji kont uprzywilejowanych oraz ekspozycji usług SSH na poziomie całej infrastruktury.