Luka „sshole” w OpenSSH: za długie hasło wpuszczało na zablokowane konta

Badacz bezpieczeństwa Ozgun Kultekin opisał podatność nazwaną „sshole”. Dotyczy ona połączenia OpenSSH z biblioteką musl. Według Spider's Web w ściśle określonych konfiguracjach można było zalogować się hasłem na konto, które w ogóle nie powinno przyjmować haseł. Wystarczył ciąg dłuższy niż 256 znaków. Kultekin twierdzi, że problem w tej postaci mógł istnieć od 2016 roku.

Jak działał błąd

W uniksowych systemach znak „*” w polu hasła w pliku /etc/shadow oznacza konto zablokowane dla logowania hasłem. Gwiazdka nie jest poprawnym skrótem hasła, więc żadne wpisane hasło nie powinno pasować.

Na błąd złożyło się kilka osobno rozsądnych decyzji. W 2012 roku twórcy musl zmienili działanie funkcji crypt(). Przy błędzie zaczęła zwracać „”, a nie wartość NULL. W tym samym roku musl wprowadził obsługę SHA-512 crypt z limitem 256 bajtów hasła. Po jego przekroczeniu operacja kończyła się błędem, czyli wynikiem „”.

W 2016 roku OpenSSH łatał podatność CVE-2016-6210, która pozwalała ustalać istniejące nazwy użytkowników po różnicach w czasie odpowiedzi. Poprawka wymuszała kosztowną operację także dla kont bez użytecznego skrótu hasła, również tych z „”. W efekcie serwer porównywał „” z „*” i wpuszczał użytkownika.

Kogo to dotyczy

Nie jest to uniwersalny sposób na włamanie do dowolnego Linuksa. Atak wymaga spełnienia kilku warunków naraz:

• serwer OpenSSH działa w środowisku z musl, np. Alpine Linux, OpenWrt, Buildroot lub Yocto,
• uwierzytelnianie PAM jest wyłączone,
• włączone jest logowanie SSH hasłem,
• w systemie jest konto z „*” oraz inne konto z prawidłowym skrótem hasła.

W takiej konfiguracji konto z „*” przyjmowało ciągi o długości od 257 do 1024 znaków. Luka nie omija poprawnie ustawionego hasła zwykłego konta. Debian, Ubuntu i Fedora, które używają glibc, nie są podatne na ten mechanizm. Nie są też podatne konfiguracje z uwierzytelnianiem przez PAM.

Według Kultekina oficjalne obrazy Alpine dla AWS i Azure zawierają dotknięte problemem domyślne konto „alpine”. Ma ono mieć możliwość używania doas bez hasła, więc dostęp do niego mógłby prowadzić do uprawnień roota. Systemy OpenWrt, Buildroot i Yocto spotyka się w routerach i systemach wbudowanych.

Rola AI w odkryciu

Badacz mówi, że korzystał z agentów AI, ale nie w sposób magiczny. Przygotował różne kompilacje sshd (glibc, musl, z PAM i bez) i poddał je nietypowym próbom logowania. Przeprowadzono około 17 600 testów, m.in. z nietypowymi skrótami, uszkodzonymi kontami i bardzo długimi hasłami. Inaczej zachowywała się jedna kombinacja: musl bez PAM.

Poprawka i zalecenia

Problem naprawiono w OpenSSH 10.6p2. Administratorom Alpine Linux zaleca się aktualizację pakietów OpenSSH. Gdy aktualizacja nie jest od razu możliwa, jako zabezpieczenie wskazuje się wyłączenie logowania SSH hasłem. Kultekin zwraca też uwagę na zmianę w OpenSSH z 30 października 2026 roku, wprowadzoną po przeglądzie bezpieczeństwa. Według niego kod związany z błędem leżał kilka linii dalej.