В некоторых системах Linux злоумышленник мог получить root-доступ, введя пароль длиной более 256 байт. Уязвимость, получившая название *sshole от исследователя из Уэйкфилда Озгуна Кюлтекина, обнаружившего ее, может быть использована только при очень специфических условиях.
Уязвимость затрагивает некоторые системы Linux, использующие musl libc вместо традиционной библиотеки GNU C, и даже в этом случае только те, которые работают с демоном безопасной оболочки OpenSSH без модулей аутентификации Pluggable Authentication Modules (PAM) и с включенной аутентификацией по паролю.
Если эти условия соблюдены и хотя бы одна другая учетная запись имеет допустимый хэш пароля, то учетные записи, которые не должны принимать пароли, такие как root, пользователи, использующие только ключи для развертывания, и пользователи LDAP, могут быть доступны путем предоставления пароля длиной от 257 до 1024 символов. Целевые учетные записи должны иметь звездочку (*) в поле пароля, а прямой вход в систему root по-прежнему зависит от конфигурации OpenSSH.
Это может показаться нишевым, но, к сожалению, это не так.
Musl libc широко используется во встраиваемых системах Linux благодаря своему небольшому размеру. Более того, это стандартная библиотека C для Alpine Linux, которая предоставляет официальные образы для облаков AWS и Azure. Поэтому некоторые системы Alpine, работающие в этих средах, могут быть уязвимы в зависимости от их конфигурации.
Заря *sshole
Уязвимость в OpenSSH в системах Linux на базе musl существует с 2016 года, но Кюлтекин объясняет, что ее корни уходят гораздо дальше — в эпоху BSD Unix.
В 1980 году соучредитель Sun Microsystems и ветеран BSD Unix Билл Джой участвовал в разработке BSD Unix, в файле паролей которого в записи /etc/passwd для пользователя daemon содержалась одна звездочка. Звездочка не была хэшем пароля и фактически отключала аутентификацию по паролю для этой учетной записи.
В настоящее время хэши паролей обычно хранятся в /etc/shadow и содержат зашифрованную информацию, которую система использует для проверки пароля в открытом виде, введенного пользователем. Звездочки по-прежнему присутствуют для учетных записей, которые не должны принимать входы по паролю, но, как объясняет Кюлтекин в своем отчете, это не совсем надежный способ защиты.
Функция crypt(), которая генерирует хэши паролей для сравнения с сохраненными значениями, может вернуть NULL, если не может вычислить хэш. Приложения, которые не проверяют этот результат, могут аварийно завершить работу. Вместо этого разработчики musl libc решили возвращать один символ при определенных сбоях, и они выбрали звездочку.
Musl также добавила хэширование паролей на основе SHA-512 примерно в то же время, которое, как отмечает Кюлтекин, замедляется с увеличением длины пароля, что потенциально может привести к отказу в обслуживании, если кто-то заполнит сервер сверхдлинным паролем. Musl ограничивала длину паролей 256 байтами, и вы, вероятно, понимаете, к чему это ведет.
В 2016 году OpenSSH внедрила обходной путь, чтобы предотвратить перебор допустимых имен учетных записей через SSH. До этого изменения sshd мог быстрее отклонять попытки аутентификации для несуществующих пользователей, чем для допустимых учетных записей. Попытки против допустимых учетных записей занимали больше времени, потому что серверу приходилось хэшировать предоставленный пароль перед отклонением. Решением было заставить sshd выполнять фиктивное хэширование пароля для недопустимых пользователей, используя соответствующий алгоритм хэширования и соль для уменьшения различий во времени отклика.
В затронутых системах Linux на базе musl учетные записи, помеченные звездочкой вместо хэша пароля, могли быть взломаны путем предоставления пароля длиной более 256 байт — это недостаток, существующий с 2016 года. Любая система Linux на базе musl, работающая с уязвимой конфигурацией OpenSSH без PAM, с включенной аутентификацией по паролю, по крайней мере одной учетной записью, помеченной звездочкой, и другой учетной записью с допустимым хэшем пароля, может быть уязвима для атаки *sshole.
К счастью, OpenSSH быстро отреагировала, чтобы исправить эту проблему, и любая сборка OpenSSH 10.6p2 (выпущенная в четверг) или новее защищена. Альтернативно, если вы не можете обновить реализацию OpenSSH в затронутой системе, просто отключите аутентификацию по паролю и перезапустите демон SSH, и все будет в порядке.
Нет никаких признаков того, что уязвимые системы были скомпрометированы, но если вы хотите проверить, Кюлтекин включил в свой отчет простую команду CLI, которую можно использовать для проверки того, принимали ли учетные записи без пароля на чувствительной машине недавно пароль. ®
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Brandon Vigliarolo
