CVE-2026-123158: Obejście uwierzytelniania hasłem w OpenSSH wpływa na Alpine Linux

Luka bezpieczeństwa o wysokim poziomie w OpenSSH może pozwalać nieautoryzowanym zdalnym atakującym na obejście uwierzytelniania hasłem na niektórych systemach Linux, przesyłając zbyt długie hasło. Śledzone jako CVE-2026-123158 i nazwane SSHhole, luka ma wynik CVSS 3.1 wynoszący 8.1 i głównie wpływa na środowiska Linux, gdzie sshd jest powiązany z musl libc i działa bez PAM. Alpine Linux jest najważniejszą dotkniętą platformą, ponieważ jej standardowy pakiet openssh-server używa tej konfiguracji domyślnie.

Luka wynika z nieoczekiwanej interakcji między walidacją hasła w OpenSSH a implementacją crypt() w musl libc. Gdy podane jest nadmiernie długie hasło, crypt() może zwrócić ciąg *, aby wskazać błąd. Niektóre konta Linux, które są skonfigurowane bez konwencjonalnego hasła, również przechowują * w polu hasła pliku /etc/shadow. W warunkach podatności, sshd może niepoprawnie interpretować pasujące wartości jako pomyślne uwierzytelnienie.

Atakujący nie musi znać hasła użytkownika docelowego. Jeśli ujawniona usługa SSH spełnia wymagane warunki, atakujący, który może dotrzeć do usługi, może uwierzytelnić się do niektórych kont, używając hasła w podatnym zakresie długości. Wpływ zależy od uprawnień przypisanych kompromitowanemu kontu. Dostęp do uprzywilejowanego konta serwisowego lub konta zdolnego do korzystania z doas lub innej mechaniki eskalacji przywilejów może prowadzić do całkowitego kompromitacji systemu.

Skontaktuj się z Działem Sprzedaży

OpenSSH rozwiązało problem w Portable OpenSSH 10.6p2, wydanym 5 listopada 2026. Alpine Linux jednocześnie wydało poprawione pakiety OpenSSH dla wszystkich wspieranych gałęzi i kilku starszych gałęzi. Zespół OpenSSH opisuje wydanie jako zawierające krytyczne obejście bezpieczeństwa dla systemów Linux używających musl libc z wyłączonym PAM.

Publiczne środowiska reprodukcji i materiały proof-of-concept są już dostępne. Jednakże, jak dotąd 6 listopada 2026, sprawdzone źródła nie raportują o potwierdzonej eksploatacji luki w rzeczywistych atakach, a luka nie została dodana do katalogu CISA Known Exploited Vulnerabilities.

Organizacje mogą wzmocnić obronę przed pojawiającymi się lukami w obejściu uwierzytelniania dzięki AI-Native Detection Intelligence Platform od SOC Prime, przyspieszając wykrywanie zagrożeń i inżynierię wykrywania w środowiskach SIEM, EDR, XDR i Data Lake.

Zespoły bezpieczeństwa mogą również używać Prime Architect do przekształcania danych o lukach w zapytania do polowania i logikę wykrywania dostosowaną do dostępnych SSH, uwierzytelniania, telemetrii punktów końcowych i sieci.

Wykryj CVE-2026-123158, monitorując pomyślne logowania do SSH bazujące na haśle na konta, które normalnie używają tylko uwierzytelniania kluczami, nietypowe próby uwierzytelnienia zawierające nienormalnie długie hasła, niespodziewany zdalny dostęp do kont serwisowych i aktywności po uwierzytelnieniu niezgodne z normalnym zachowaniem konta.

Treści dotyczące wykrywania mogą nie być dostępne dla każdego CVE. Sprawdź bieżącą pokrycia na platformie SOC Prime. Jeśli odpowiednie wykrycia nie są jeszcze dostępne, sprawdź ponownie, ponieważ nowe dane wywiadowcze i treści dotyczące wykrywania są stale dodawane.

Analiza CVE-2026-123158

CVE-2026-123158 dotyczy OpenSSH sshd przed Portable OpenSSH 10.6p2, kiedy działa na Linuxie z musl libc i proces uwierzytelniania hasłem zachodzi bez PAM. CVE ma wynik CVSS 3.1 wynoszący 8.1 z wektorem AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, odzwierciedlającym zdalną eksploatację bez wcześniejszych przywilejów lub interakcji użytkownika, ale wymagającą określonej konfiguracji systemu i konta.

Źródłem problemu jest interakcja między OpenSSH a funkcją haszującą hasło dostarczaną przez musl libc.

Na systemach, gdzie PAM jest wyłączony, sshd wykonuje walidację hasła używając funkcji crypt() systemu. Dla typowego konta /etc/shadow zawiera kryptograficzny hasz hasła, a wartość wygenerowana z podanego hasła użytkownika jest porównywana z tym przechowywanym haszem.

musl libc zachowuje się inaczej, gdy dostarczone hasło przekracza obsługiwaną długość wejściową. Dla haseł dłuższych niż 256 bajtów, crypt() zwraca * jako wartość błędu zamiast zwykłego hasza hasła.

Problem powstaje, ponieważ * jest również powszechnie używane w /etc/shadow dla kont, które nie mają skonfigurowanego tradycyjnego hasła.

Jeśli podatne sshd otrzymuje zbyt długie hasło dla jednego z tych kont, przepływ uwierzytelniania może efektywnie porównać * zwrócone przez crypt() z * przechowywanym we wprowadzeniu do shadow konta. Wartości pasują, a uwierzytelnianie może niepoprawnie zakończyć się sukcesem.

Opis CVE stwierdza, że dla dotkniętych konfiguracji konta, hasła pomiędzy 256 a 1024 znaków mogą prowadzić do pomyślnego uwierzytelnienia. Niezależne odtworzenia opisują hasła przekraczające normalną granicę 256 bajtów jako wystarczające do osiągnięcia podatnego stanu.

Wada nie jest więc uniwersalnym obejściem hasła dotyczące każdej implementacji OpenSSH.

Kilka określonych warunków musi się zbiec.

Po pierwsze, serwer musi używać musl libc. Alpine Linux jest głównym przykładem mainstreamowym, choć inne systemy wbudowane lub minimalne środowiska Linux mogą również używać musl.

Po drugie, sshd musi uwierzytelniać użytkowników bez PAM. Standardowy pakiet openssh-server systemu Alpine jest zbudowany bez PAM, podczas gdy alternatywna konfiguracja openssh-server-pam jest chroniona, gdy UsePAM jest ustawione tak.

Po trzecie, uwierzytelnianie hasłem musi być włączone. PasswordAuthentication tak to odpowiednia konfiguracja. Systemy skonfigurowane do uwierzytelniania tylko za klucze publiczne, z PasswordAuthentication nie są narażone na udokumentowaną ścieżkę ataku.

Ostatecznie, atakujący potrzebuje konta, którego pole hasła zawiera *. Mogą to być użytkownicy tylko z kluczami, konta utworzone bez haseł, niektóre tożsamości dostarczane przez usługi katalogowe i niektórzy użytkownicy obrazów w chmurze.

Alpine odnotowuje również dodatkowy warunek: co najmniej jedno lokalne konto musi zawierać hasz hasła w stylu $5$ lub $6$, aby podatna ścieżka uwierzytelniania działała zgodnie z opisem.

Konto root zasługuje na szczególną uwagę. Alpine często przechowuje root:*, ale domyślne ustawienie OpenSSH PermitRootLogin prohibit-password zapobiega bezpośredniemu uwierzytelnianiu hasłem na konto root. W rezultacie standardowa instalacja Alpine nie automatycznie ujawnia bezpośredniego logowania do roota przez ten błąd.

Ochrona ta nie eliminuje szerszego ryzyka. Jeśli inne konto z * w polu hasła jest dostępne zdalnie i ma prawa administracyjne przez doas, sudo, możliwości kontenera lub inne uprzywilejowane mechanizmy, pomyślne uwierzytelnienie może nadal zapewnić ścieżkę do całkowitego kompromitacji systemu.

Oficjalne obrazki tiny-cloud systemu Alpine są szczególnie istotne. Badania nad bezpieczeństwem zidentyfikowały wersje, w których konto alpine mogło spełniać warunki podatne i było również w stanie używać doas do uzyskania podwyższonych uprawnień. To ilustruje, dlaczego obrońcy powinni oceniać uprawnienia konta, zamiast zakładać, że podatność zapewnia albo nieszkodliwy dostęp użytkownika, albo automatyczny dostęp do roota w każdym środowisku.

Dystrybucje Linux bazujące na glibc, takie jak Debian, Ubuntu i RHEL, nie są dotknięte tym konkretnym podatnością, ponieważ podatne zachowanie zależy od implementacji haszowania hasła musl libc. Systemy używające PAM do walidacji hasła SSH również znajdują się poza dokumentowaną konfiguracją podatną.

Kontenery wymagają podobnych kwalifikacji. Alpine jest powszechnie używane jako obraz bazowy dla kontenerów, ale zwykłe kontenery, które nie uruchamiają sshd, nie są narażone przez tę ścieżkę ataku. Głównym zagrożeniem są kontenery, urządzenia, środowiska developerskie lub przestarzałe obciążenia, które wyraźnie instalują i eksponują serwer SSH.

Landskejty PoC dla CVE-2026-123158 rozwijają się szybko. Publiczne laboratoria odtworzeniowe są bezpośrednio wymienione w rejestrze luki, demonstrując, że obrońcy powinni założyć, że obejście uwierzytelniania można odtworzyć bez dostępu do prywatnych badań eksploatacyjnych. To znacząco podnosi pilność remedialną, nawet jeśli nie zgłoszono jeszcze potwierdzonej złośliwej eksploatacji.

Luka została zgłoszona przez Özgüna Kültekina z Wakefield. OpenSSH publicznie wydało wersję 10.6p2 z obejściem bezpieczeństwa 5 listopada 2026. Sprawdzone główne źródła nie określają dokładnej daty, kiedy badacz pierwotnie odkrył lub prywatnie zgłosił problem.

Poprawka OpenSSH dodaje walidację zaprojektowaną w celu uniemożliwienia akceptowania wartości błędów i niepoprawnych krótkich haszy hasła podczas uwierzytelniania hasłem. OpenSSH zauważa, że uważa podstawową przyczynę leżącą poza sshd, ale ponieważ warunek ten można wykorzystać przez serwer SSH, projekt zaimplementował defensywne obejście w samym OpenSSH.

Alpine Linux wstecznie aplikował poprawkę w wielu gałęziach:

Gałąź Alpine	Poprawiony pakiet OpenSSH
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

Administratorzy powinni polegać na stanie pakietu dystrybucyjnego zamiast samego bannera wersji SSH. Dystrybucje Linux często aplikują poprawki bezpieczeństwa bez zmiany wyświetlanej wersji OpenSSH podczas negocjacji SSH. Serwer wyświetlający starszy ciąg wersji może więc już zawierać poprawkę od sprzedawcy.

Dla wykrycia CVE-2026-123158 obrońcy powinni priorytetowo traktować telemetrię uwierzytelniania SSH. Szczególnie mocnym sygnałem do polowania jest pomyślne logowanie hasłem do konta, które ma zamiar użyć tylko uwierzytelniania kluczami publicznymi lub które nie ma skonfigurowanego użytecznego hasła.

Na systemach Alpine, administratorzy mogą przeglądać /var/log/messages, scentralizowane logi uwierzytelniania, rejestry SIEM lub równoważną telemetrię pod kątem zdarzeń Accepted password dotyczących nieoczekiwanych kont serwisowych, tylko z kluczami lub administracyjnych.

Obrońcy powinni korelować pomyślne uwierzytelnienie z adresami IP źródła, czasami logowania, czasem trwania sesji, wykonywanymi poleceniami po zalogowaniu, podniesieniem przywilejów, zmianami w authorized_keys, tworzeniem kont, zaplanowanymi zadaniami i nieoczekiwanymi połączeniami sieciowymi wychodzącymi.

Telemetria sieciowa może również pomóc w identyfikacji odsłoniętych systemów. Zdalnie dostępne usługi SSH reklamujące uwierzytelnianie hasłem lub interaktywną klawiaturę powinny otrzymać wyższy priorytet naprawczy, zwłaszcza gdy system wsparcia to Alpine lub inna dystrybucja bazująca na musl.

Obecnie nie ma kampanii-specyficznych IOCs dla CVE-2026-123158 takich jak potwierdzone adresy IP atakujących, domeny, hasze złośliwego oprogramowania lub infrastruktura dowodzenia i kontroli. Brak statycznych wskaźników sprawia, że monitorowanie zachowań uwierzytelniania SSH i późniejszej aktywności sesji jest szczególnie ważne.

Łagodzenie skutków CVE-2026-123158

Podstawowe działanie naprawcze polega na zainstalowaniu OpenSSH 10.6p2 lub poprawionego pakietu dostarczonego przez dystrybucję Linux. Administratorzy Alpine powinni zaktualizować cały system, używając bieżących repozytoriów pakietów, i ponownie uruchomić sshd po tym. Samo zaktualizowanie pakietu nie zastępuje już uruchomionego procesu demona SSH.

Organizacje korzystające z kontenerów bazujących na Alpine powinny odbudować i ponownie wdrożyć każdy obraz, który instaluje openssh-server. Samo zaktualizowanie systemu operacyjnego hosta nie załata podatnych pakietów OpenSSH osadzonych wewnątrz obrazów kontenerów.

Administratorzy powinni również zidentyfikować ekspozycję, zanim założą, że każdy host Alpine jest podatny. Kluczowe kontrole obejmują:

1. Ustal, czy host używa musl libc.
2. Zweryfikuj, czy sshd działa z wyłączonym PAM.
3. Sprawdź, czy uwierzytelnianie hasłem jest włączone.
4. Zidentyfikuj konta zdolne do logowania, których pole /etc/shadow hasło to *.
5. Przejrzyj uprawnienia przypisane do tych kont.
6. Potwierdź zainstalowany pakiet OpenSSH z poprawioną wersją pakietu od dystrybucji.

Jeśli natychmiastowe łatanie nie jest możliwe, organizacje powinny wyłączyć uwierzytelnianie hasłem SSH.

Skonfiguruj:

PasswordAuthentication no

i, gdzie ma to zastosowanie:

KbdInteractiveAuthentication no

Administratorzy powinni potwierdzić działanie uwierzytelniania kluczami publicznymi przed zastosowaniem tej konfiguracji, aby uniknąć utraty prawidłowego dostępu administracyjnego.

Konfiguracja SSH powinna następnie zostać zweryfikowana, a demon przeładowany lub ponownie uruchomiony. Następnie, zewnętrzna weryfikacja powinna potwierdzić, że serwer oferuje tylko uwierzytelnianie kluczami publicznymi.

Ograniczenie dostępności sieciowej zapewnia dodatkową obronę. SSH ogólnie powinien być dostępny tylko z zaufanych sieci administracyjnych, infrastruktury VPN, hostów bastionowych lub wyraźnych list dozwolonych źródeł IP, zamiast być powszechnie eksponowanym w Internecie.

Organizacje powinny również rozważyć, czy SSH w ogóle jest wymagane wewnątrz kontenerów. Nowoczesne środowiska orkiestracji zwykle oferują alternatywy takie jak docker exec lub kubectl exec, eliminując niepotrzebną zdalnie dostępną usługę uwierzytelniania.

Dla potencjalnie wystawionych systemów, przeglądaj historyczne, pomyślne logowania hasłem przed naprawą. Zwróć szczególną uwagę na konta skonfigurowane bez haseł i tożsamości, które normalnie oczekuje się, że uwierzytelnią się wyłącznie kluczami SSH.

Jeśli zidentyfikowane zostanie niespodziewane, pomyślne logowanie, traktuj konto jako potencjalnie skompromitowane. Przeglądaj historię powłoki, gdzie dostępna, wykonywanie procesów, eskalację przywilejów, nowe lub zmodyfikowane wpisy authorized_keys, zmiany użytkowników i grup, zadania cron, skrypty startowe, instalację pakietów i połączenia sieciowe wychodzące.

Poświadczenia i klucze dostępne dla skompromitowanego konta powinny być traktowane jako potencjalnie ujawnione i rotowane zgodnie z wynikami dochodzenia. Jeśli konto posiadało uprawnienia administracyjne, obrońcy powinni rozszerzyć dochodzenie na cały host i wszystkie systemy dostępne przy użyciu przechowywanych tam poświadczeń.

Publiczny materiał dowodowy PoC oznacza, że organizacje nie powinny czekać na dowody powszechnych ataków przed zastosowaniem naprawy. Wymagania dotyczące eksploatacji zawężają podatną populację, ale systemy, które spełniają te warunki, mogą być dostępne zdalnie bez znajomości prawidłowego hasła.