Уязвимость Alpine Linux в связке с OpenSSH позволяет удалённо войти на сервер через SSH, зная лишь имя подходящей учётной записи и отправив специально подобранный пароль длиной от 257 до 1024 байт. Ошибка затрагивает популярный лёгкий дистрибутив, который часто используют в контейнерах, облачных образах и embedded-средах: администраторам стоит обновить пакеты и перезапустить sshd, а не просто поставить обновление «на потом».
Проблему обнаружила группа *sshole; уязвимость Alpine Linux получила идентификатор CVE-2026-123158. Как сообщает ZDNet, атака срабатывает с первого подключения и не требует перебора паролей. Это особенно неприятный сценарий для серверов, доступных из интернета: SSH обычно остаётся одним из самых защищаемых входов в инфраструктуру, а здесь защита ломается на обработке ошибки в библиотеке.
Корень проблемы — в реализации функции crypt() в musl libc. Alpine Linux использует эту компактную стандартную библиотеку вместо распространённой glibc. Когда OpenSSH собран без PAM и проверяет пароль, он хеширует присланное значение через crypt(), а затем сравнивает результат с полем пароля в учётной записи. Для пароля длиннее 256 байт musl возвращает строку * как признак ошибки. Тем же символом обычно помечаются аккаунты без пароля — например, учётные записи, для которых разрешён только вход по SSH-ключу.
В результате OpenSSH получает совпадение там, где должен был отклонить аутентификацию. Атакующему нужен логин аккаунта с символом * в поле пароля, а на машине должен быть хотя бы один пользователь с хешем пароля формата 5 или 6. По данным Alpine, одного такого пользователя достаточно, чтобы открыть доступ ко всем подходящим passwordless-аккаунтам. Root в типовой конфигурации не становится прямой жертвой: по умолчанию его вход с паролем запрещён параметром PermitRootLogin prohibit-password. Но если скомпрометированный пользователь может повысить привилегии через doas, практическая разница быстро исчезает.
Уязвимыми Alpine признала проверенные ветки с 3.16 по 3.24 и edge. Для эксплуатации должны одновременно выполняться несколько условий: установлен openssh-server без PAM либо openssh-server-pam с UsePAM no; PasswordAuthentication включён; есть аккаунт с * в поле пароля и хотя бы один пользователь с подходящим хешем. Дистрибутив отдельно выделил официальные tiny-cloud-образы версий 3.18.11–3.24.3. В них есть пользователь alpine с отключённым паролем и passwordless doas. После первой загрузки образ безопасен, но настройка консольного пароля или создание пользователя через пользовательские данные обычно добавляет нужный хеш и делает конфигурацию уязвимой.
Не все системы на Alpine требуют аварийных работ. Контейнеры без запущенного sshd не подвержены атаке. Также защищены серверы с отключённой парольной аутентификацией, конфигурации openssh-server-pam с UsePAM yes и заблокированные аккаунты, у которых в поле пароля стоит !, а не *. Cloud-образы, настроенные через cloud-init, как правило, выставляют PasswordAuthentication no. Обычные Debian, Ubuntu и Fedora также не попадают под проблему: в glibc crypt() возвращает при такой ошибке NULL, который sshd отклоняет.
Alpine уже выпустила версии 3.21.10, 3.22.8, 3.23.8 и 3.24.4, а исправленные пакеты доступны и для веток до 3.16. В стабильных ветках применён патч, а OpenSSH 10.6p2 устраняет проблему на своей стороне. Базовая последовательность действий выглядит так:
- выполнить apk upgrade -U -a;
- перезапустить службу командой rc-service sshd restart;
- если обновление пока невозможно — отключить PasswordAuthentication и перезапустить sshd, предварительно проверив вход по ключу.
Последний пункт критичен: обновление пакета не заменяет уже работающий процесс sshd. Сервер может выглядеть обновлённым в отчёте о пакетах и при этом продолжать принимать опасные подключения старым демоном. Для команд, которые сопровождают десятки VM или Kubernetes-узлов на Alpine, это повод проверить не только версию пакета, но и состояние сервиса после раскатки.
Проверка на возможную эксплуатацию начинается с поиска в /var/log/messages строк вида Accepted password for, относящихся к аккаунтам без пароля. Alpine также рекомендует проверить использование doas, недавно созданных пользователей, файлы и изменения в authorized_keys. Если нельзя уверенно исключить вход злоумышленника, машину следует считать скомпрометированной: сменить ключи и секреты, изучить логи и при необходимости восстановить хост из доверенного образа. Эта уязвимость Alpine Linux напоминает неприятную, но полезную вещь: минимальный образ не равен минимальной поверхности атаки, если в нём остаётся SSH с настройками по умолчанию.
