257 байт «абракадабры» вместо пароля. OpenSSH пускал посторонних с первой попытки

8250
257 байт «абракадабры» вместо пароля. OpenSSH пускал посторонних с первой попытки

Десять лет опасная ошибка скрывалась в механизме, которому доверяли миллионы серверов.

image

Разработчики OpenSSH выпустили экстренное обновление 10.6p2, закрывающее SSHhole, уязвимость, которая позволяла обходить парольную защиту отдельных Linux-аккаунтов. Для атаки хватало одного подключения и произвольной строки длиной от 257 байт.

Уязвимость получила идентификатор CVE-2026-123158 и оценку 8,1 балла по CVSS 3.1. Проблема затрагивает не все установки OpenSSH. Для атаки сервер должен работать на Linux с библиотекой musl, использовать OpenSSH без PAM и разрешать вход по паролю. На машине также должна существовать учётная запись со знаком «*» вместо хеша и хотя бы один другой пользователь с хешем пароля SHA-256 или SHA-512. Злоумышленнику достаточно знать имя целевой учётной записи и иметь доступ к SSH-порту.

Звёздочка в системном файле /etc/shadow означает, что учётная запись не должна принимать пароль. Такой способ часто используют для аккаунтов, которым разрешён вход только по SSH-ключам. Значение должно быть именно «*», а не «!», которым блокируют аккаунт полностью. В уязвимой конфигурации OpenSSH без PAM, механизма подключения модулей аутентификации, сервер использует соль другого пользователя, чтобы время ответа не выдавало существование логина.

Ошибка возникла на стыке OpenSSH и musl. Функция crypt() в библиотеке musl отклоняет пароли длиннее 256 байт и возвращает «*» как признак ошибки. OpenSSH сравнивал полученный результат с полем целевой учётной записи, где уже стояла такая же звёздочка, и ошибочно принимал совпадение за успешную аутентификацию. Подходят любые строки длиной от 257 до 1024 байт. Подробный технический разбор показывает, как несколько изменений в разных проектах за годы превратились в одну серьёзную проблему.

Уязвимость могла присутствовать в OpenSSH начиная с версии 7.3p1, выпущенной в 2016 году, но проявляется только при сочетании всех необходимых условий. В Alpine Linux риск особенно заметен, поскольку стандартный пакет openssh-server собран без PAM, а парольная аутентификация включена по умолчанию. Само наличие Alpine в контейнере не означает угрозу. Контейнеры без запущенного SSH-сервера не подвержены атаке.

Особую опасность представляют официальные облачные образы Alpine для AWS и Azure. В них предусмотрена учётная запись alpine, которая может запускать команды с правами администратора через doas, аналог sudo, без дополнительного пароля. Если на сервере появляется подходящий хеш пароля другого пользователя, атакующий может войти как alpine и повысить привилегии до root. Прямой вход в root зависит от настройки PermitRootLogin и по умолчанию ограничен.

Под потенциальный риск попадают и сборки на базе Buildroot и Yocto, если разработчики выбрали musl и OpenSSH без PAM. OpenWrt требует отдельной оговорки. По умолчанию система использует SSH-сервер Dropbear, который не затронут SSHhole. Уязвимость может проявиться после установки OpenSSH и включения соответствующих настроек. Debian, Ubuntu и Fedora используют glibc и от проблемы защищены.

Исследователь Озгюн Кюльтекин из компании Wakefield обнаружил проблему 3 ноября. Для поиска ошибки он проверил около 17 600 вариантов входа с разными конфигурациями OpenSSH, библиотеками glibc и musl, а также включённым и отключённым PAM. Уязвимое поведение проявилось только в сборке OpenSSH на musl без PAM. По словам исследователя, разработчики OpenSSH подготовили исправление менее чем за час после получения сообщения.

5 ноября команда OpenSSH выпустила версию 10.6p2. Разработчики считают, что первопричина находится за пределами самого sshd, однако добавили защитную проверку непосредственно в серверный компонент, чтобы исключить ошибочное сравнение некорректных хешей. Alpine Linux одновременно подготовила исправленные пакеты для веток с 3.16 по 3.24 и edge. Патчи вошли в Alpine 3.21.10, 3.22.8, 3.23.8 и 3.24.4. Для более старых веток также выпустили отдельные обновления.

Установка обновления не заменяет уже работающий процесс sshd, поэтому после обновления администраторам необходимо перезапустить SSH-сервер. Если установить исправление сразу невозможно, временной мерой станет отключение парольной аутентификации с помощью директивы PasswordAuthentication no. Перед изменением настройки следует убедиться, что доступ по SSH-ключам работает, чтобы не потерять возможность управления сервером.

Администраторам также рекомендуют проверить журналы авторизации. Записи Accepted password для учётных записей, в которых вместо хеша стоит «*», могут указывать на успешную эксплуатацию SSHhole. По состоянию на 6 ноября подтверждённых сообщений об использовании уязвимости в реальных атаках не появилось. Однако исследователь уже опубликовал проверочный скрипт и демонстрационный эксплойт, поэтому технические подробности атаки доступны всем желающим.

Главная сложность для администраторов заключается в том, что проблема затрагивает не только привычные серверные дистрибутивы. Alpine широко используют в контейнерной инфраструктуре и облачных образах, а musl встречается в прошивках и специализированных Linux-сборках. Поэтому проверять следует не только виртуальные машины и серверы, но и устройства, в которых разработчики самостоятельно собрали OpenSSH. При этом наличие уязвимой библиотеки само по себе ещё не означает возможность атаки.