Пароль длиной от 257 до 1024 символов мог дать доступ к учётной записи, для которой вход по паролю формально отключён. Уязвимость OpenSSH musl затрагивает не все Linux-серверы, но её условия встречаются в Alpine Linux и встраиваемых системах — то есть там, где компактность дистрибутива часто важнее привычного набора защитных слоёв.
Проблему обнаружил исследователь Özgün Kültekin, который назвал её *sshole; сообщает The Register. Разработчики OpenSSH выпустили исправление в версии 10.6p2, опубликованной 5 ноября. Для команд, использующих Alpine-образы в облаке, это повод не откладывать обновление sshd в бэклог под названием «когда-нибудь после релиза».
Атака возможна только при довольно узком наборе условий. Система должна использовать библиотеку musl libc вместо glibc; SSH-сервер должен работать без PAM; парольная аутентификация должна быть включена; а в системе нужна как минимум одна учётная запись с корректным хешем пароля. Целевой аккаунт при этом должен иметь символ * в поле пароля — так обычно помечают учётные записи, которым нельзя входить с паролем.
В потенциально уязвимой конфигурации длинный пароль может обмануть проверку таких аккаунтов. Под ударом оказываются root, пользователи, которым разрешён только вход по SSH-ключу, а также LDAP-учётные записи без локального пароля. Прямой вход под root всё равно зависит от параметра PermitRootLogin: сама ошибка не отменяет отдельные ограничения конфигурации OpenSSH.
Корень проблемы — в различиях обработки ошибок функцией crypt(). При невозможности вычислить хеш многие реализации возвращают NULL, и приложение обязано корректно это обработать. В musl для некоторых ошибок возвращается строка из одного символа — звёздочки. Исторически этот же символ применяют как маркер заблокированного пароля. Совпадение двух старых инженерных решений оказалось достаточно неприятным.
Дополнительную роль сыграло изменение OpenSSH 2016 года. Тогда sshd научили выполнять фиктивное хеширование пароля для несуществующих пользователей, чтобы нельзя было определить наличие аккаунта по разнице во времени ответа. Идея правильная: без неё атакующий мог бы перебирать имена пользователей, измеряя задержку аутентификации. Но в связке с musl она создала обход для записей со звёздочкой вместо пароля.
Musl ограничивает длину пароля 256 байт. Это сделано в том числе потому, что SHA-512-хеширование становится дороже с ростом длины входной строки и может превратиться в инструмент для отказа в обслуживании. Если передать строку длиннее лимита, обработка в уязвимой цепочке приводит к тому самому значению *, которое затем ошибочно совпадает с маркером отключённого пароля. Уязвимость OpenSSH musl в этом случае не требует подбора настоящего пароля жертвы.
Почему это важно для Alpine и инфраструктуры
Сценарий не выглядит массовым эксплойтом для любого SSH-сервера в интернете. На системах с glibc он не работает, а PAM в типичных серверных установках добавляет ещё один барьер. Однако musl — стандартная библиотека Alpine Linux, а Alpine выпускает официальные облачные образы для AWS и Azure. Лёгкие контейнеры и минимальные ВМ нередко получают упрощённую аутентификацию именно потому, что их считают временными, внутренними или слишком маленькими для серьёзной угрозы. Обычно именно после такого допущения они и становятся постоянными.
Для разработчиков и DevOps-команд первоочередная задача проста: проверить версию OpenSSH и фактическую конфигурацию, а не только версию базового образа в Dockerfile. Обновление до OpenSSH 10.6p2 или более новой версии закрывает проблему. Если обновление нельзя провести сразу, OpenSSH рекомендует отключить парольную аутентификацию и перезапустить sshd. Это разумная временная мера и для серверов, где пароли уже давно не должны использоваться, но настройка пережила несколько миграций.
Полезно также инвентаризировать учётные записи со звёздочкой в теневых паролях, проверить значение PasswordAuthentication, наличие PAM и правила прямого входа root. Отдельное внимание — шаблонам развёртывания: уязвимый образ может не быть публично доступным, но жить в CI-раннере, админской ВМ или давно забытом сервисе. По данным публикации, признаков эксплуатации пока нет, однако автор исследования описал способ проверить, не пытались ли недавно аутентифицироваться по паролю в аккаунт без пароля.
История *sshole хорошо показывает цену защитных «заплаток» на стыке старого Unix-наследия, библиотек и мер против побочных каналов. В ближайшие дни важнее всего не спор о том, насколько редка комбинация условий, а аудит собственных Alpine- и musl-хостов: одна включённая опция парольного входа способна превратить нишевую ошибку в вполне прикладной инцидент. Детали исследования и условия эксплуатации собраны в материале .
