Раскрыта новая критическая уязвимость CVE - SSHole (OpenSSH) на Alpine Linux

Критическая уязвимость OpenSSH (SSHole) позволяет войти на сервер без знания пароля - достаточно отправить пароль длиннее 256 символов. Затрагивает Alpine Linux и другие системы на библиотеке musl (Alpine - база большинства Docker-образов).

Сервер должен отклонять неверный пароль. Но в некоторых конфигурациях OpenSSH на Alpine Linux слишком длинная строка приводила к обратному результату: проверка завершалась успешно. Эта уязвимость получила название SSHole. Настоящий пароль знать не требовалось, однако для атаки должны были совпасть несколько условий.

5 ноября 2026 года вышел OpenSSH 10.6p2 с защитой от этой критической уязвимости. Разработчики считают, что её первопричина находится за пределами OpenSSH, но закрыли возможность эксплуатации через SSH-сервер. На момент публикации предупреждения Alpine идентификатор CVE ещё не был присвоен.

Как длинный пароль проходил проверку

Обычно Linux хранит хеш пароля - результат его преобразования специальной функцией. При входе система обрабатывает введённый пароль и сравнивает результат с сохранённым значением.

Но в поле пароля файла /etc/shadow может стоять просто *. Это не хеш и не пустой пароль. Такая запись используется для аккаунтов, которые не должны проходить парольную проверку: например, пользователь может подключаться по SSH-ключу.

В варианте без PAM - отдельного механизма аутентификации- OpenSSH проверяет пароль самостоятельно. Если сохраненная запись слишком короткая, как в случае со звёздочкой, он может взять параметры хеширования из другой учётной записи. В том числе соль - дополнительное значение, используемое при вычислении хеша. Эта логика появилась при исправлении утечки информации по времени ответа в 2016 году.

Дальше вмешивается musl - базовая системная библиотека, которую использует Alpine Linux. В описанном сценарии пароль длиннее 256 байт заставляет функцию crypt() вернуть маркер ошибки: ту же самую *.

Получается цепочка: слишком длинный пароль → ошибка хеширования → результат * → сравнение с сохранённой * → успешная проверка. Два одинаковых служебных значения принимаются за совпадение пароля.

Описанный диапазон составляет от 257 до 1024 байт. Именно байт: количество символов зависит от их кодировки.

А нашел этот баг Özgün Kültekin - с помощью ИИ агентов. Заменят ли нас ИИ агенты?

Какие серверы затрагивает (*)SSHole

Для описанного сценария должны одновременно выполняться следующие условия:

• Работает уязвимый SSH-сервер OpenSSH на musl, и атакующий может к нему подключиться.

• Пароли проверяются без PAM. В Alpine это стандартный openssh-server либо openssh-server-pam с настройкой UsePAM no.

• Разрешён парольный вход: PasswordAuthentication yes.

• Есть доступная через SSH учётная запись со значением ровно * в поле пароля.

• Есть другая локальная учётная запись с хешем пароля, начинающимся на $5$ или $6$.

Контейнер на Alpine без работающего sshd через эту уязвимость не атакуется. Одного названия Alpine в Dockerfile недостаточно, чтобы считать систему уязвимой.

Описанный обход также не затрагивает обычные системы на glibc, включая стандартные установки Debian, Ubuntu и Fedora, а также OpenBSD, Dropbear и конфигурации OpenSSH, где парольную аутентификацию обрабатывает PAM.

Как защититься: обновить пакеты и перезапустить SSH

Alpine рекомендует обновить пакеты и обязательно перезапустить sshd. Простая установка обновления не заменяет уже работающий процесс SSH-сервера.

На обычной системе Alpine с OpenRC выполните с правами root:

apk upgrade -U -a &&
sshd -t &&
rc-service sshd restart

Первая команда обновляет пакеты из настроенных репозиториев. sshd -t проверяет корректность конфигурации и ключей; перезапуск выполняется только при успешном завершении предыдущих команд.

Проверить установленные версии пакетов OpenSSH:

apk info -v | grep '^openssh'

Обновляйтесь в рамках своей ветки: Alpine перенёс исправление и в предыдущие версии OpenSSH. Поэтому защищённый пакет может иметь номер ниже 10.6p2. При проверке учитывайте полный номер, включая окончание -r…. Исправления также выпущены для старых веток 3.16–3.19.

Если sshd работает внутри контейнера, пересоберите образ с исправленными пакетами и разверните контейнер заново. Обновление образа само по себе не обновляет уже запущенные контейнеры.

Что сделать, если обновиться пока нельзя

Временно отключите парольный вход в действующей конфигурации SSH-сервера:

PasswordAuthentication no

Перед изменением проверьте, что можете подключиться по ключу. Текущую сессию оставьте открытой до проверки нового подключения.

Учитывайте подключаемые конфигурационные файлы и блоки Match: они могут задавать отдельные правила для пользователей и подключений. После изменения проверьте конфигурацию и перезапустите службу:

sshd -t && rc-service sshd restart

Посмотреть итоговую общую настройку можно так:

sshd -T | grep '^passwordauthentication '