Проблема специфична для систем на библиотеке musl: Alpine, OpenWrt, Buildroot, Yocto и десятки Docker-образов, которые собирают на их основе. В glibc-дистрибутивах вроде Debian, Ubuntu и Fedora, а также при включённом PAM уязвимости нет.
Механика в том, как OpenSSH проверяет пароль в такой сборке. Если у учётной записи в /etc/shadow стоит * — то есть пароль не задан и вход должен идти только по ключу, — а в системе есть хотя бы одна другая учётная запись с настоящим паролем, то для «звёздочной» записи принимается любой пароль длиной от 257 до 1024 символов. Проверка фактически сравнивает не то, что должна.
Кого это касается
Тех, у кого выполняются все условия сразу: musl, отсутствие PAM, разрешён вход по паролю, есть запись с * и есть другая запись с паролем. В официальных образах Alpine для AWS и Azure так настроен пользователь alpine, у которого к тому же есть право на doas без пароля — то есть на практике это путь до root.
Уязвимость существует с 2016 года. Утверждений об эксплуатации в реальных атаках в публичных материалах нет, но отсутствие подтверждения здесь слабое утешение: вход по паролю в таких системах часто включён «по умолчанию», а логи почти никто не читает.
Что делать
Обновиться до OpenSSH 10.6p2 — самый простой путь. Если обновление недоступно, выключить вход по паролю: в Alpine достаточно положить PasswordAuthentication no в отдельный файл в sshd_config.d и перезапустить службу.
После этого стоит проверить журналы на строки «Accepted password» для учётных записей, которые по паролю пускать не должны, — особенно если sshd смотрел в интернет.
The problem is specific to systems using the musl library: Alpine, OpenWrt, Buildroot, Yocto and the many Docker images built on them. glibc distributions such as Debian, Ubuntu and Fedora, and anything with PAM enabled, are not affected.
The mechanics lie in how OpenSSH checks passwords in such a build. If an account’s /etc/shadow entry contains * — meaning no password is set and login should use keys only — and the system has at least one other account with a real password, then any password between 257 and 1024 characters is accepted for the starred entry. The check is effectively comparing the wrong thing.
Who is affected
Those where all conditions hold at once: musl, no PAM, password login enabled, an account with *, and another account with a password. In the official Alpine images for AWS and Azure the default alpine user is set up this way, and it also has passwordless doas rights — in practice, a path to root.
The flaw has existed since 2016. Public materials do not claim exploitation in real attacks, but that is thin comfort: password login is often on by default in such systems, and almost nobody reads the logs.
What to do
Update to OpenSSH 10.6p2 — the simplest route. If updating is impossible, turn password authentication off: on Alpine, put PasswordAuthentication no in a separate file under sshd_config.d and restart the service.
Afterwards, check logs for “Accepted password” on accounts that should never accept one — especially if sshd was reachable from the internet.