Уязвимость в OpenSSH и musl libc позволяет войти в аккаунт без пароля через длинную строку

Уязвимость во взаимодействии OpenSSH и библиотеки musl libc позволяет атакующему войти в учётную запись с отключённым паролем, отправив через SSH строку длиной от 257 до 1024 байт. В первую очередь затронуты серверы Alpine Linux, где пакет openssh-server собран без поддержки PAM. Для эксплуатации достаточно одного подключения — атака срабатывает с первой попытки. Исправление доступно в OpenSSH 10.6p2 и обновлённых пакетах Alpine для веток с 3.16 по 3.24. Администраторам затронутых систем необходимо немедленно обновить пакеты и перезапустить sshd либо отключить парольную аутентификацию.

Технические детали уязвимости

Уязвимости присвоен идентификатор CVE-2026-123158 — согласно записи в GitHub Advisory Database, она оценена как высокой степени серьёзности с предварительным баллом CVSS 8.1. Следует учитывать, что эта запись имеет статус «unreviewed», а ни OpenSSH, ни Alpine собственной оценки CVSS не публиковали.

Согласно бюллетеню безопасности Alpine Linux, для эксплуатации необходимо одновременное выполнение четырёх условий:

• Сервер использует пакет openssh-server без PAM (или openssh-server-pam с UsePAM no);
• Параметр PasswordAuthentication установлен в yes (значение по умолчанию в OpenSSH);
• У целевой учётной записи в поле пароля в /etc/shadow стоит * — то есть пароль не задан (типично для аккаунтов, использующих только SSH-ключи);
• В системе существует хотя бы одна другая учётная запись с хешем пароля формата $5$ (SHA-256 crypt) или $6$ (SHA-512 crypt).

Стоит отметить расхождение в источниках относительно минимальной длины пароля, запускающего уязвимость: бюллетень Alpine указывает 257 байт, тогда как запись в GitHub Advisory Database — 256 байт. Верхняя граница в обоих случаях составляет 1024 байта — это ограничение самого sshd.

Механизм уязвимости

Проблема возникает на стыке трёх компонентов: обработки ошибок в функции crypt() библиотеки musl, механизма проверки паролей в sshd без PAM и формата хранения данных об учётных записях.

Когда sshd работает без PAM, он самостоятельно хеширует введённый пароль через crypt() и сравнивает результат с сохранённым значением. Для аккаунтов без пароля в поле хеша хранится символ *. Поскольку эта строка слишком коротка для извлечения соли, sshd заимствует соль у другой учётной записи, имеющей настоящий хеш. Этот механизм заимствования соли был введён в 2016 году для устранения уязвимости CVE-2016-6210, позволявшей определять существующие имена пользователей по времени ответа сервера.

Ключевой элемент — поведение musl: при обработке хешей $5$ и $6$ функция crypt() отказывается работать с паролями длиннее 256 байт и возвращает * как индикатор ошибки. Это решение было принято в 2012 году — вместо возврата NULL при ошибке musl стал возвращать «несовпадающий хеш», поскольку многие программы не проверяли NULL. Однако возвращаемое значение * совпадает с тем, что хранится в /etc/shadow для аккаунтов без пароля, и sshd считает проверку успешной.

Примечательно, что разработчики OpenSSH и musl расходятся в оценке первопричины. Согласно примечаниям к выпуску OpenSSH 10.6p2, команда OpenSSH считает корень проблемы внешним по отношению к sshd, хотя эксплуатацию можно предотвратить на его стороне. Разработчик musl Рич Фелкер, в свою очередь, указывает, что проблема — в том, как вызывающая программа обрабатывает возвращаемое значение crypt().

Масштаб воздействия

Затронуты все версии Alpine Linux с 3.16 по 3.24 и ветка edge при наличии описанной конфигурации. Системы на базе glibc, а также любые конфигурации с включённым PAM уязвимости не подвержены.

Особого внимания заслуживают облачные образы Alpine на базе tiny-cloud версий с 3.18.11 по 3.24.3. В них присутствует учётная запись alpine с полем пароля * и правом выполнять команды через doas без пароля. Такие образы безопасны при первом запуске, но становятся уязвимыми, как только в системе появляется хотя бы один хеш формата $6$ — например, после того как администратор задаст пароль для консольного доступа. В этом случае атакующий может войти как alpine и получить права root через doas.

Учётная запись root по умолчанию защищена настройкой PermitRootLogin prohibit-password, однако это не помогает, если скомпрометированный аккаунт имеет возможность повышения привилегий.

Что касается других систем на musl — исследователь Озгюн Кюльтекин из компании Wakefield, обнаруживший уязвимость, упоминает OpenWrt, Buildroot и Yocto как платформы, требующие проверки. Однако практический радиус поражения уже, чем может показаться: штатный OpenWrt использует Dropbear в качестве SSH-сервера, как следует из документации OpenWrt, и Dropbear уязвимости не подвержен. Проблема актуальна для OpenWrt только в случае ручной установки OpenSSH администратором.

Публичный PoC для воспроизведения уязвимости уже доступен, однако сообщений об эксплуатации в реальных атаках на момент публикации не поступало.

Рекомендации по устранению

Согласно бюллетеню Alpine, для устранения уязвимости необходимо:

1. Обновить пакеты: apk upgrade -U -a
2. Перезапустить sshd: rc-service sshd restart — обновление пакета не перезапускает работающий процесс sshd автоматически.

Исправленные пакеты включены в точечные релизы Alpine 3.21.10, 3.22.8, 3.23.8 и 3.24.4. Ветки 3.16–3.20, уже вышедшие из регулярной поддержки, также получили исправления.

При самостоятельной сборке OpenSSH следует обновиться до версии 10.6p2, содержащей обходное решение — sshd теперь отклоняет совпадение, если сохранённое поле пароля короче четырёх символов.

Если немедленное обновление невозможно, необходимо отключить парольную аутентификацию:

• Убедиться, что вход по SSH-ключу работает, и не закрывать текущую сессию до проверки нового подключения;
• Установить PasswordAuthentication no в конфигурации sshd;
• Проверить конфигурацию: sshd -t;
• Перезапустить sshd;
• Убедиться в результате: sshd -T | grep -i passwordauthentication должен вывести passwordauthentication no.

Для выявления возможной компрометации бюллетень Alpine рекомендует проверить /var/log/messages на наличие записей Accepted password for для учётных записей без пароля — таких как alpine, root или аккаунты, использующие только ключи. На потенциально скомпрометированных машинах следует также проверить использование doas, недавно созданных пользователей, файлы и авторизованные ключи. Как указано в бюллетене: «Если вы не можете исключить факт входа — считайте машину скомпрометированной».

Администраторам Alpine Linux с включённым SSH-доступом следует обновить пакеты и перезапустить sshd в первую очередь на облачных экземплярах tiny-cloud версий 3.18.11–3.24.3, где сочетание уязвимости с правами doas создаёт прямой путь к получению root. На всех остальных затронутых системах приоритет обновления определяется наличием четырёх описанных условий — если хотя бы одно из них не выполнено, система не подвержена данной атаке.