Критична уязвимост в OpenSSH може да позволи на отдалечени атакуващи да заобиколят удостоверяването с парола на засегнати сървъри с Alpine Linux, включително за акаунти, предназначени само за достъп с ключ. OpenSSH пусна Portable 10.6p2 на 5 ноември 2026 г., за да блокира проблема, който засяга Linux системи, използващи musl libc без PAM удостоверяване.
Изследване, публикувано на sshhole.com от Özgün Kültekin от Wakefield, обяснява как необичайно дълга парола може да превърне неуспешна проверка на парола в успешен вход. Alpine потвърждава, че при наличие на необходимите условия за експлоатация са нужни една връзка, достъпен SSH порт и известно име на акаунт.
Целевият акаунт трябва да има * в полето за парола, докато друг локален акаунт трябва да съдържа хеш на парола от вида $5$ или $6$. Удостоверяването с парола също трябва да остане разрешено. Това означава, че добавянето на парола към един акаунт може да изложи на риск други акаунти, създадени без пароли.
Стандартният пакет openssh-server на Alpine не използва PAM, което прави конфигурацията от значение. Системите с openssh-server-pam и UsePAM yes не са засегнати. Контейнерите без работещ SSH сървър също не са засегнати, така че използването само на контейнерен образ на Alpine не означава наличие на риск.
Разкриването следва по-ранни корекции за сигурност в OpenSSH 10.6, но този проблем се отнася до проверката на пароли, а не до криптирането. При публикуването на съвета на Alpine не е бил присвоен CVE идентификатор.
Заобикаляне на удостоверяването с парола в OpenSSH
Техническият анализ на изследователя проследява грешката до взаимодействие между OpenSSH и функцията crypt() на musl. Без PAM sshd хешира подадената парола и сравнява резултата със записаното поле за парола. За акаунт, чието поле съдържа само *, sshd заема солта на друг акаунт.
Когато подадената парола надвишава 256 байта, съответният код на musl за хеширане на пароли я отхвърля и връща * като маркер за грешка. Този маркер съвпада със записаното поле на целевия акаунт. Вместо входът да бъде отхвърлен, сравнението е успешно. Alpine посочва, че паролите с дължина между 257 и 1024 байта задействат проблема.
На уязвими системи парола от 300 повторени символа „A“ може да заобиколи удостоверяването за засегнат акаунт. Паролата не е нужно да съответства на реална тайна. Вместо това дължината є предизвиква грешка във функцията за хеширане на musl, която връща същия маркер *, записан за този акаунт.
Комиксът от изследователя показва как отделни промени в обработката на пароли се събират с времето. Той свързва използването на * за акаунти без използваема парола, съвпадащия маркер за грешка на musl и поведението на OpenSSH със заетата сол. Заедно те обясняват как дълга парола може да премине проверка, която е трябвало да я отхвърли.
Изследователят свързва веригата с промяна в OpenSSH от 2016 г., целяща да намали откриването на потребителски имена чрез разлики във времето за отговор. Тестове с различни настройки на библиотеката и удостоверяването разкриват несъответствието при musl без PAM. Това е различно от по-ранни уязвимости в клиента и сървъра на OpenSSH, свързани с прихващане и прекъсване на услугата.
Официалните образи tiny-cloud на Alpine от 3.18.11 до 3.24.3 съдържат акаунт alpine с достъп до doas без парола. Те стават уязвими, когато се добави хеш на парола, отговарящ на условията. Тогава атакуващ може да влезе като alpine и да получи root права. Стандартните ограничения все пак блокират директния вход като root с парола, освен ако администраторите не ги променят.
Следвайте указанията на Alpine за отстраняване, като изпълните apk upgrade -U -a, след което rc-service sshd restart. Само обновяването оставя стария процес да работи. Коригираните версии включват 3.21.10, 3.22.8, 3.23.8 и 3.24.4, а за по-старите клонове има налични пакети с корекции за сигурност.
По-старите клонове също получиха пакети с корекции, така че по-ниският номер на версията на OpenSSH не означава автоматично, че системата остава уязвима.
Когато инсталирането на корекциите трябва да изчака, задайте PasswordAuthentication no, потвърдете, че достъпът с ключ работи, и рестартирайте sshd, като държите отворена съществуваща сесия. Прегледайте /var/log/messages за записи Accepted password for, свързани с акаунти без парола, след което проверете за неочаквана активност на doas и нови оторизирани ключове.
Бележките към версията на OpenSSH потвърждават временното решение от разработчиците. Alpine съветва машините да се третират като компрометирани, когато неоторизиран достъп не може да бъде изключен.