Пароль длиной от 257 байт открывает аккаунт на Linux с musl
Исследователь Озгюн Кюльтекин обнаружил уязвимость на стыке OpenSSH и библиотеки musl, а разработчики выпустили исправление 5 ноября 2026 года. Уязвимость затрагивает серверы SSH с включённой парольной аутентификацией и отключённым PAM.
Проблема проявляется на системах с библиотекой musl, в том числе Alpine Linux, OpenWrt, Buildroot и Yocto. Нападающему нужен доступ к порту SSH и имя подходящей учётной записи. Для входа достаточно одного соединения, если остальные условия уязвимости уже выполнены. Кюльтекин назвал ошибку «*sshole» и сообщил, что она существовала с 2016 года.
Администратор может запретить парольный вход в учётную запись, записав вместо хеша пароля звёздочку (*) в файл /etc/shadow. Поскольку звёздочка не является действительным хешем, ни один введённый пароль не должен с ней совпасть. Однако на затронутом сервере пароль чрезмерной длины вызывает ошибку в функции crypt() библиотеки musl. Функция возвращает ту же звёздочку, и OpenSSH принимает совпадение за успешную проверку.
Для атаки недостаточно одного такого аккаунта. На сервере также должна быть другая учётная запись с действительным хешем пароля, а парольная аутентификация SSH должна оставаться включённой. В техническом разборе уточняется, что при проверке аккаунта со звёздочкой sshd заимствует соль из другой учётной записи. Для подходящего хеша указаны префиксы $5$ или $6$. Добавление пароля одному пользователю может создать условия для входа в другую учётную запись, у которой парольный вход был запрещён.
По данным Alpine, ошибку вызывают пароли длиной от 257 до 1024 байт. Например, на уязвимой системе сработать может строка из 300 букв A: она не совпадает с настоящим секретом, а лишь заставляет функцию хеширования вернуть маркер ошибки. При этом аккаунты с действительными хешами паролей уязвимость не открывает. Нужен именно сохранённый символ * в поле пароля целевой учётной записи.
Как появилась уязвимость OpenSSH
В 2016 году разработчики OpenSSH исправляли другую уязвимость, CVE-2016-6210. По различиям во времени ответа она позволяла определять существующие имена пользователей. После исправления OpenSSH стал выполнять хеширование пароля даже для учётных записей без пригодного хеша. Это касалось и аккаунтов, где запрет парольного входа обозначен звёздочкой.
В musl функция crypt() тоже возвращает * при ошибке хеширования, в том числе когда переданный пароль превышает её предел в 256 байт. При работе без PAM сервер сравнивает полученное значение с полем пароля из /etc/shadow. Если в этом поле уже записана звёздочка, маркер ошибки выглядит как совпадение. Поэтому изменения в OpenSSH после исправления CVE-2016-6210 привели к тому, что ошибка в musl могла дать успешную проверку пароля.
Кюльтекин сообщил, что нашёл уязвимость с помощью ИИ-агентов. Они провели около 17 600 проверок аутентификации, меняя настройки OpenSSH, некорректные хеши и длину паролей. На момент публикации предупреждения Alpine этой ошибке ещё не присвоили идентификатор CVE.
Стандартный пакет openssh-server в Alpine не использует PAM, поэтому для атаки должны совпасть и остальные условия. Системы с glibc, включая Debian, Ubuntu и Fedora, этой атаке не подвержены. Она также не работает при аутентификации через PAM, в частности с пакетом openssh-server-pam и настройкой UsePAM yes. Само наличие образа контейнера Alpine ещё не означает уязвимость: в контейнере должен работать сервер SSH.
Кого затрагивает ошибка и как закрыть доступ
Отдельный риск связан с облачными образами Alpine для AWS и Azure. В них есть учётная запись alpine, которой разрешено запускать команды через doas без пароля. В образах tiny-cloud версий от 3.18.11 до 3.24.3 она становится доступной для описанной атаки, если на машине появляется другой аккаунт с подходящим хешем. После входа под именем alpine нападающий может получить права root. Прямой парольный вход в root по умолчанию остаётся запрещённым, если администратор не менял ограничения.
Уязвимость исправлена в OpenSSH Portable 10.6p2. Для Alpine названы исправленные выпуски 3.21.10, 3.22.8, 3.23.8 и 3.24.4; обновлённые пакеты получили и более старые ветки. Поэтому версия OpenSSH с более низким номером сама по себе не доказывает, что система остаётся уязвимой. Администраторам Alpine рекомендуют установить обновления командой apk upgrade -U -a и затем перезапустить сервер командой rc-service sshd restart: без перезапуска продолжит работать прежний процесс.
Если обновиться сразу нельзя, парольную аутентификацию SSH можно отключить настройкой PasswordAuthentication no. Перед перезапуском sshd нужно проверить вход по ключу; в рекомендациях также советуют сохранить уже открытую сессию. Эта мера закрывает описанный способ входа до установки исправленного пакета. Она относится именно к серверам, где парольная аутентификация ещё включена.
Следы возможного входа можно искать в /var/log/messages по строке Accepted password. Если такая запись относится к аккаунту, которому парольный вход запрещён, его поле пароля следует сверить с /etc/shadow. Для учётной записи alpine сочетание успешного входа по паролю и символа * в этом поле может указывать на эксплуатацию ошибки. В рекомендациях также предлагают проверить неожиданную активность doas и новые ключи в authorized_keys; Alpine советует считать машину скомпрометированной, если исключить посторонний доступ не удаётся.
