OpenSSH пропускал длинные пароли в чужие аккаунты. Под угрозой часть серверов на Alpine

В OpenSSH закрыли уязвимость sshhole, которая позволяла войти в определённые учётные записи без знания пароля. Атакующему достаточно было отправить строку длиной от 257 до 1024 байт. Проблема затрагивает некоторые системы с библиотекой musl и отключённым PAM — механизмом, через который Linux-приложения могут проверять учётные данные.

Исправление вышло 5 ноября в OpenSSH 10.6p2. Alpine также подготовила обновления своих пакетов, включая версии для старых веток дистрибутива.

Ошибка превращала отказ проверки в успешный вход

В Linux пароль обычно хранится в виде хеша — результата специального преобразования. При входе сервер обрабатывает введённую строку тем же способом и сравнивает результаты. У аккаунтов без установленного пароля вместо хеша может стоять символ *: например, если пользователь должен подключаться по SSH-ключу.

Уязвимость возникла на стыке двух механизмов. При определённых условиях OpenSSH использовал соль — параметр хеширования — другой учётной записи. Функция crypt() из musl при обработке слишком длинного пароля возвращала * как признак ошибки. Сервер сравнивал этот результат со звёздочкой в поле пароля и разрешал вход. Исследователь описал эту последовательность в разборе sshhole.

Для эксплуатации должны одновременно выполняться несколько условий:

• SSH-сервер работает с musl без использования PAM;
• парольная аутентификация разрешена;
• у целевой учётной записи в поле пароля стоит *;
• в системе есть другая учётная запись с хешем пароля формата $5$ или $6$.

Атакующему также нужны доступ к SSH-порту и имя подходящего пользователя. Поэтому установленный Alpine сам по себе ещё не означает уязвимость: контейнер без запущенного SSH-сервера под этот сценарий не попадает.

В облачных образах вход мог привести к правам root

Alpine подтвердила проблему в официальных образах tiny-cloud. В них пользователь alpine имеет поле пароля * и может выполнять административные команды через doas без дополнительного пароля.

На первом запуске такие образы безопасны. Уязвимая комбинация появляется, если позднее в системе создают подходящий хеш пароля — например, администратор задаёт пароль для консоли. Тогда атакующий может войти как alpine и повысить привилегии.

Прямой вход под root зависит от конфигурации: стандартное значение PermitRootLogin prohibit-password блокирует парольную аутентификацию этой учётной записи. Но оно не защищает от входа через другого пользователя с административными полномочиями.

После установки исправления необходимо перезапустить sshd: обновление пакета не заменяет уже работающий процесс. Если обновиться сразу нельзя, Alpine рекомендует отключить парольную аутентификацию, предварительно проверив вход по ключу.

Защита от одной атаки стала частью другой

Один из элементов этой цепочки появился в 2012 году. Тогда musl изменила обработку ошибок crypt(): вместо нулевого указателя функция стала возвращать специальную строку. Ограничение длины пароля помогало сдерживать нагрузку на процессор при хешировании.

В 2016 году OpenSSH добавил выбор соли для проверки несуществующих пользователей. Это должно было затруднить определение существующих аккаунтов по времени ответа сервера. Спустя десять лет сочетание этого поведения с обработкой ошибок в musl позволило обойти проверку пароля.

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