Уязвимости Уязвимость в OpenSSH и musl позволяет обойти SSH-аутентификацию в Linux

Независимый ИБ-исследователь Озгюн Кюльтекин (Özgün Kültekin) обнаружил уязвимость Для просмотра ссылки Войди или Зарегистрируйся, которая возникает при взаимодействии OpenSSH и библиотеки musl libc. При определенной конфигурации Linux-системы баг позволяет войти в учетную запись с отключенной парольной аутентификацией, просто отправив через SSH слишком длинный пароль.


Уязвимость, которой еще не присвоили идентификатор CVE, затрагивает Linux-системы с musl libc, где OpenSSH работает без PAM и разрешена парольная аутентификация. То есть в первую очередь речь идет об Alpine Linux, однако проблема может затрагивать и другие системы, собранные с использованием musl, в том числе решения на базе Buildroot и Yocto. Отдельно Кюльтекин упоминает OpenWrt, если вместо штатного Dropbear там установлен OpenSSH.



Корень проблемы заключается в том, как sshd осуществляет проверку паролей. В Linux для учетной записи можно заблокировать вход по паролю, указав * вместо хеша в /etc/shadow. В результате такой аккаунт, например, может использовать только SSH-ключи, и никакой пароль для него подходить не должен.


Однако в 2016 году разработчики OpenSSH исправили уязвимость CVE-2016-6210, которая позволяла определять существующие имена пользователей по времени ответа сервера. Для этого sshd стал выполнять хеширование пароля даже для тех учетных записей, для которых вход по паролю фактически отключен. То есть атакующие более не могли определить имена пользователей по разнице во времени ответа.


Как выяснилось теперь, в системах с musl после выхода этого патча возник неожиданный побочный эффект: при использовании SHA-256 crypt или SHA-512 crypt функция crypt() отказывается обрабатывать пароли длиннее 256 байт и возвращает * как признак ошибки. Однако то же значение может храниться в /etc/shadow для учетной записи с отключенной парольной аутентификацией. В результате sshd сравнивает полученную * со значением * в /etc/shadow и считает проверку успешной.


Кюльтекин объясняет, что для осуществления атаки нужно соблюсти ряд условий:

• OpenSSH работает без PAM;
• включена парольная аутентификация (PasswordAuthentication yes);
• для целевого аккаунта в /etc/shadow указано * вместо хеша;
• в системе должна быть хотя бы одна активная учетная запись с паролем в формате SHA-256 crypt или SHA-512 crypt ($5$ или $6$), поскольку sshd берет из ее хеша соль для проверки.

Если все условия соблюдены, атакующему достаточно знать имя целевой учетной записи и при подключении через SSH ввести пароль длиной от 257 до 1024 байт.


Новая проблема особенно опасна для Alpine Linux, где пакет openssh-server собран без PAM, и разработчики Для просмотра ссылки Войди или Зарегистрируйся, что атака на *sshhole срабатывает с одной попытки.


Более того, отдельный риск связан с официальными облачными образами Alpine Linux для AWS и Azure. В некоторых из них присутствует учетная запись alpine, которой разрешено выполнять команды через doas без пароля, и компрометация такого аккаунта может привести к получению root-прав. При этом напрямую войти через SSH под root по умолчанию нельзя: стандартная настройка OpenSSH PermitRootLogin prohibit-password запрещает парольную аутентификацию для этой учетной записи.


Следует отметить, что разработчики OpenSSH и musl расходятся во мнениях о том, на чьей именно стороне находится ошибка. В OpenSSH Для просмотра ссылки Войди или Зарегистрируйся, что первопричина возникновения бага лежит за пределами sshd, хотя эксплуатацию уязвимости можно предотвратить на его стороне. В свою очередь, разработчик musl Рич Фелкер (Rich Felker) Для просмотра ссылки Войди или Зарегистрируйся, что корень проблемы заключается не в работе musl, а в том, как вызывающая программа обрабатывает значение, которое crypt() возвращает при ошибке.


Защиту от *sshhole добавили в Для просмотра ссылки Войди или Зарегистрируйся, а разработчики Alpine уже выпустили исправленные версии пакетов. Если установить обновления пока по какой-то причине невозможно, рекомендуется отключить парольную аутентификацию (PasswordAuthentication no) и перезапустить sshd.


Для просмотра ссылки Войди или Зарегистрируйся