OpenSSH закрыла критический обход SSH-аутентификации в Alpine Linux
OpenSSH выпустила версию 10.6p2 для устранения критической ошибки, которая на части серверов Alpine Linux позволяла войти по SSH в учётную запись без пароля. Для атаки требовались сетевой доступ, имя такой учётной записи и пароль длиной от 257 до 1024 байт. Alpine Linux уже опубликовала исправленные пакеты для всех веток, начиная с 3.16.
Какие системы подвержены ошибке
Проблема возникает при одновременном выполнении нескольких условий: установлен openssh-server без PAM либо openssh-server-pam с отключённым UsePAM, разрешён PasswordAuthentication, а у одной из локальных учётных записей в поле пароля указан символ *. Кроме того, хотя бы у одной другой учётной записи должен быть хеш пароля, начинающийся с $5$ или $6$.
Стандартный пакет openssh-server в Alpine собран без PAM, а парольная аутентификация включена по умолчанию. В число потенциально уязвимых попадают пользователи, созданные только для входа по ключу, root с записью root:*, а также пользователь alpine в некоторых официальных образах tiny-cloud. Для root по умолчанию действует PermitRootLogin prohibit-password, но это не исключает повышения привилегий через доступные пользователю механизмы, например doas.
Контейнеры без запущенного sshd, машины с PasswordAuthentication no, инстансы, настроенные cloud-init, а также учётные записи, заблокированные символом ! в /etc/shadow, не подвержены этой атаке. OpenSSH отмечает, что системы на glibc, не-Linux платформы и конфигурации с проверкой паролей через PAM также не затронуты.
Почему длинный пароль проходил проверку
Без PAM демон sshd сам вызывает функцию crypt() и сопоставляет её результат с сохранённым полем пароля. Для учётной записи без пароля поле содержит только *, поэтому sshd заимствует соль из хеша другой учётной записи. В musl функция crypt() для хешей $5$ и $6$ отклоняет пароль длиннее 256 байт и возвращает * как признак ошибки. Этот символ совпадал с сохранённым полем, после чего вход принимался.
В OpenSSH 10.6p2 добавлена проверка: sshd отказывает в совпадении, если сохранённое поле короче четырёх символов. Проект называет это обходным исправлением, поскольку исходная причина связана с поведением внешней библиотеки. Уязвимость может касаться и других систем на musl: исследователь Özgün Kültekin рекомендовал проверить OpenWrt, Buildroot и Yocto. В OpenWrt по умолчанию используется Dropbear, который, по его данным, не затронут.
Что сделать администраторам
На Alpine следует обновить пакеты командой apk upgrade -U -a и отдельно перезапустить службу командой rc-service sshd restart: само обновление не перезапускает работающий sshd. Исправленный пакет уже включён в Alpine 3.21.10, 3.22.8, 3.23.8 и 3.24.4; обновления также выпущены для снятых с поддержки веток 3.16–3.21.
Если обновление пока невозможно, парольный вход нужно отключить, предварительно убедившись, что аутентификация по SSH-ключу работает, и не закрывая текущую сессию до успешной проверки нового подключения. После изменения конфигурации её следует проверить через sshd -t и убедиться, что sshd -T выводит passwordauthentication no.
Администраторам стоит просмотреть /var/log/messages на строки Accepted password для пользователей без пароля, проверить использование doas, недавно созданные учётные записи, файлы и authorized_keys. Контекст Linux-атак дополняет риски руткитов, сетевого 0-day и атак с ИИ, где рассматриваются риски руткитов, сетевого 0-day и атак с ИИ. Если исключить несанкционированный вход нельзя, Alpine рекомендует считать машину скомпрометированной.
Практический вывод
Для бизнеса первоочередная задача — инвентаризировать Alpine-инстансы с доступным из сети SSH, установить обновления и проверить, что парольная аутентификация отключена там, где она не нужна. После обновления важно подтвердить перезапуск sshd и провести проверку признаков входа в учётные записи без пароля.