OpenSSH на musl: вход любым длинным паролем к учётным записям без пароля, исправление в 10.6p2

OpenSSH 10.6p2 закрывает обход парольной аутентификации в sshd на Linux с musl и без PAM. На Alpine Linux, OpenWrt, Buildroot и Yocto любой пароль длиннее 256 символов подходит к учётной записи, у которой пароль не задан, включая root при разрешённом входе. Уязвимость получила идентификатор CVE-2026-123158. Атакующему достаточно доступа к SSH-порту: одна попытка входа без знания пароля и без перебора, а в журнале остаётся строка об успешном входе.

Что известно об ошибке в sshd

Корень проблемы

sshd без PAM проверяет пароль через crypt(): хеширует попытку с солью из сохранённого поля и сравнивает результат. Если поле равно звёздочке, соли в нём нет. Чтобы выровнять время ответа и не выдавать существование учётных записей, sshd берёт соль другого аккаунта. Этот механизм появился в 2016 году как защита от перечисления пользователей.

В musl функция crypt() не возвращает NULL при ошибке, а отдаёт строку из одного символа. Для sha512-crypt вход длиннее 256 байт отклоняется, и crypt() возвращает звёздочку. Она совпадает с сохранённым полем учётной записи без пароля, поэтому проверка проходит. В записи CVE причина описана как неверная трактовка строки: код не отличает признак ошибки от хеша. Класс ошибки - CWE-394, неожиданный код возврата.

История растянулась на годы. Звёздочка как пометка «вход по паролю запрещён» известна с 1980-х: это не хеш, и подобрать к ней пароль нельзя. В 2012 году musl заменил возврат NULL на звёздочку при ошибке crypt() и вскоре ограничил вход sha512-crypt 256 байтами. В 2016 году в sshd добавили обход для защиты от перечисления пользователей: для учётных записей без соли он стал брать соль другого аккаунта. Спустя десять лет эти решения встретились.

Кого затрагивает

Условия складываются одновременно. sshd собран без PAM: так устроен пакет openssh-server в Alpine, также подходит openssh-server-pam с UsePAM no. Вход по паролю не отключён, а PasswordAuthentication yes стоит по умолчанию. В системе есть учётная запись со звёздочкой в поле пароля и хотя бы одна учётная запись с хешем $5$ или $6$.

Звёздочка стоит у root в базовом образе Alpine примерно с 3.16, у key-only пользователей, созданных без пароля, у пользователей каталога через musl-nscd и у пользователя alpine в официальных облачных образах tiny-cloud. По умолчанию PermitRootLogin prohibit-password закрывает root, но при PermitRootLogin yes или при возможности повышения прав через doas ограничение не спасает.

Пользователи каталога попадают в список потому, что у них нет записи в локальном файле теней: соли для них нет, и sshd уходит в уязвимую ветку. В облачных образах tiny-cloud пользователь alpine создан без пароля и с doas без пароля, поэтому вход под ним сразу даёт root. Образы безопасны на первом запуске, но становятся уязвимыми, когда на машине появляется любой хеш $6$.

Уязвимы выпуски Alpine с 3.16 по 3.24 и edge. Версия 3.21 потеряла регулярную поддержку 1 ноября 2026 года, но исправленные пакеты выпустили и для неё, и для более старых 3.16-3.20.

Не затронуты системы с glibc и PAM, контейнеры без sshd, хосты с PasswordAuthentication no, сборки openssh-server-pam с UsePAM yes и машины, где нет ни одной учётной записи с долларовым хешем. Заблокированные учётные записи с восклицательным знаком в поле пароля тоже не подходят.

Чем опасен вход без пароля

Атакующий получает оболочку от имени учётной записи без пароля. На официальных облачных образах Alpine это пользователь alpine с doas без пароля, то есть сразу root. На других системах это может быть служебная учётная запись.

9 ноября 2026 года CVE-2026-123158 добавили в каталог CISA KEV. Попадание в каталог означает подтверждённую эксплуатацию в реальных атаках, а не только лабораторный сценарий. CISA в разметке SSVC оценивает эксплуатацию как активную, а автоматизируемость - как отсутствующую: атакующему нужно знать имя учётной записи без пароля. Техническое воздействие при этом полное. Оценка MITRE - CVSS 3.1 8.1 (High) с вектором CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

Исправленные версии

OpenSSH выпустила 10.6p2 5 ноября 2026 года. В релизном объявлении команда называет исправление критическим обходным механизмом и отмечает, что корень ошибки лежит вне sshd, но закрыть её можно в sshd. Релиз вышел внепланово: команда сообщила, что из-за потока отчётов об ошибках, в том числе найденных с помощью ИИ, переходит на более частые выпуски.

Alpine обновила пакеты для всех поддерживаемых и части неподдерживаемых выпусков: 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. Точечные выпуски 3.21.10, 3.22.8, 3.23.8 и 3.24.4 уже содержат исправление.

В Debian штатные сборки используют glibc и PAM, поэтому трекер помечает срочность как unimportant, а в unstable пакет обновлён до 1:10.6p2-1; bookworm и trixie по версии остаются уязвимыми. Ошибку нашёл Özgün Kültekin из Wakefield, исправление подготовили Damien Miller и Darren Tucker.

Что делать

Обновите пакет openssh и перезапустите sshd. Обновление пакета не заменяет работающий демон, поэтому без перезапуска защита не включается. В облачных образах tiny-cloud обновлять нужно каждый запущенный экземпляр: образы до 3.21.10, 3.22.8, 3.23.8 и 3.24.4 уязвимы.

Если обновиться нельзя, отключите вход по паролю: добавьте PasswordAuthentication no в конфигурацию sshd и перезапустите службу. Перед этим убедитесь, что вход по ключу работает, и не закрывайте текущую сессию до проверки нового подключения. В Alpine настройку можно положить отдельным файлом в каталог sshd_config.d, проверить конфигурацию через sshd -t, перезапустить службу через rc-service sshd restart и убедиться, что sshd -T показывает passwordauthentication no. Откат - удалить файл и восстановить резервную копию конфигурации.

Как проверить следы входа

Ищите в /var/log/messages строки Accepted password для учётных записей без пароля: alpine, root и key-only пользователей. Проверьте использование doas, новых пользователей, изменённые файлы и добавленные ключи в authorized_keys. Если исключить вход не удаётся, машину стоит считать скомпрометированной.

На облачных образах tiny-cloud отдельно проверьте, не задавали ли пароль консоли и не добавляли ли пользователя с хешем: именно это превращает образ в уязвимый.