Уязвимость OpenSSH позволяет авторизоваться в некоторых Linux-аккаунтах, где вход по паролю должен быть заблокирован: достаточно отправить пароль длиннее 256 байт. Под ударом оказались системы на musl, включая Alpine Linux, OpenWrt, Buildroot и Yocto; для российских команд это особенно неприятно там, где Alpine используется в контейнерах, edge-устройствах и облачных образах.
Проблему обнаружил исследователь безопасности Озгюн Кюльтекин. Как сообщает BleepingComputer, баг получил неформальное имя *sshole и существует с 2016 года. Исправление уже вошло в OpenSSH 10.6p2, а администраторам Alpine рекомендуют обновить пакет командой apk upgrade openssh.
Механика атаки выглядит почти карикатурно, но причина вполне инженерная. В файле /etc/shadow парольную запись аккаунта можно заменить символом *. Это не хеш пароля, поэтому обычная проверка не должна подобрать к нему ни один пароль. Такой способ используют, когда учётную запись нужно оставить в системе, но исключить для неё аутентификацию по паролю.
После исправления CVE-2016-6210 OpenSSH начал вычислять хеш и для аккаунтов без пригодного парольного хеша. Это было нужно, чтобы не выдавать существование пользователя разницей во времени ответа: классическая защита от перечисления логинов. На системах с библиотекой musl функция crypt() при ошибке возвращает тот же символ *. Ошибка возникает, в частности, если пароль превышает лимит в 256 байт. В результате сервер сравнивает звёздочку, полученную при неудачном хешировании слишком длинного пароля, со звёздочкой в /etc/shadow и принимает их за совпадение.
Это не универсальный обход всех SSH-паролей. Уязвимость OpenSSH не помогает войти в аккаунт с нормальным валидным хешем: пароль пользователя она не раскрывает и не подбирает. Эксплуатация требует сочетания нескольких условий: SSH-сервер должен работать на дистрибутиве с musl, PAM-аутентификация должна быть отключена, вход по паролю должен быть разрешён, а хотя бы у одной учётной записи в поле пароля должна стоять звёздочка. Исследователь также указывает на наличие в конфигурации другого аккаунта с валидным хешем.
В Alpine Linux риск заметнее из-за настроек пакета openssh-server: PAM там по умолчанию не используется. Отдельная зона внимания — официальные cloud-образы Alpine для AWS и Azure. В них есть затронутая учётная запись alpine, а ей доступны беспарольные привилегии через doas. Если атакующий получает SSH-сессию от её имени, история может быстро закончиться правами root — без эксплуатации ядра, утечки ключей и привычного перебора паролей.
Для Debian, Ubuntu и Fedora это не повод срочно переписывать плейбуки: они используют glibc, а не musl, и описанная цепочка к ним не относится. Так же защищены конфигурации, где задействован PAM. Но инвентаризация только по названию ОС здесь легко подведёт. Alpine часто живёт не как «сервер Alpine», а внутри минимального контейнера, готового образа для CI или сетевого устройства. Командам стоит проверять именно хосты с доступным извне SSH, используемую C-библиотеку, способ аутентификации и содержимое полей паролей служебных аккаунтов.
Если обновление нельзя поставить немедленно, практичная временная мера — отключить парольную аутентификацию в конфигурации sshd: PasswordAuthentication no, затем перезапустить сервис. Это переводит доступ на ключи и убирает сам вектор атаки. Для поиска возможной эксплуатации в Alpine можно просмотреть /var/log/messages на строки Accepted password. Успешный вход по паролю для аккаунта, у которого в /etc/shadow стоит *, — сильный индикатор компрометации, а не странность журналирования.
Показательно, что Кюльтекин нашёл проблему с помощью ИИ-агентов: они выполнили около 17 600 тестов аутентификации с разными конфигурациями OpenSSH, повреждёнными хешами и oversized-паролями. Для защитников это напоминание без мистики: автоматизация теперь так же хорошо находит стыки библиотек и «безопасных» настроек, как атакующие — ошибки в бизнес-логике. В случае с musl и SSH именно такой стык превратил символ блокировки в пароль, который принимать было нельзя.
