Уязвимость regreSSHion в OpenSSH

В OpenSSH, популярном наборе инструментов для дистанционного управления *nix-системами, была найдена уязвимость, при помощи которой неаутентифицированный злоумышленник может выполнить произвольный код и получить root-привилегии. Уязвимость получила номер CVE-2024-6387 и собственное имя regreSSHion. Учитывая, что sshd, сервер OpenSSH, внедрен в большинство популярных ОС, многие устройства интернета вещей и другие девайсы вроде межсетевых экранов, описание уязвимости звучит как начало новой эпидемии уровня WannaCry и Log4Shell. На практике ситуация несколько сложнее, и массовой эксплуатации уязвимости, вероятно, не будет. Несмотря на это, все администраторы серверов с OpenSSH должны срочно позаботиться об устранении уязвимости.

Где применяется OpenSSH

Набор утилит OpenSSH встречается почти повсеместно. Это популярная реализация протокола SSH (secure shell), внедренная в подавляющее большинство дистрибутивов Linux, OpenBSD и FreeBSD, macOS, а также в специализированные устройства, например на базе Junos OS. Поскольку многие телевизоры, «умные» дверные глазки и видеоняни, сетевые медиаплееры и даже роботы-пылесосы работают на базе Linux-систем, в них тоже часто применяется OpenSSH. Начиная с Windows 10, OpenSSH есть и в ОС от Microsoft, правда, здесь это опциональный компонент, не устанавливаемый по умолчанию. Не будет преувеличением сказать, что sshd работает на десятках миллионов устройств.

В чем суть уязвимости regreSSHion

При попытке аутентификации в сервисе SSH у пользователя есть лимит времени, чтобы завершить процесс (по умолчанию это 120 секунд). Если аутентификации не случилось, сервер sshd асинхронно вызывает сигнальную функцию sigalarm, которая в свою очередь вызывает системные функции управления памятью, причем небезопасным для асинхронного выполнения образом. При выполнении атакующим ряда условий, с некоторой (достаточно небольшой) вероятностью это вызывает состояние гонки (race condition), приводящее к нарушению границ памяти и выполнению произвольного кода.

Для того чтобы проэксплуатировать уязвимость, атакующий должен совершить в среднем 10 тысяч попыток аутентификации, а атакуемая система должна быть построена на базе версий Linux, использующих библиотеку Gnu C (glibc), — например, на всех сортах ОС Debian. При этом важно подготовить структуры памяти в расчете на конкретную версию библиотеки glibc и Linux. Исследователи продемонстрировали атаку на 32-битные системы Linux, но теоретически возможна и атака на 64-битные системы, хотя вероятность успеха будет ниже. Рандомизация распределения памяти (ASLR) замедляет процесс эксплуатации, но не является гарантированной защитой.

Что интересно, эту ошибку команда OpenSSH уже устраняла в 2006 году, тогда она получила номер CVE-2006-5051. Таким образом, новая ошибка является регрессией — повторным появлением уже известного дефекта из-за новых изменений, вносимых в код. Отсюда и возникло имя для новой уязвимости.

Перспективы эксплуатации CVE-2024-6387

Уязвимость была обнаружена исследователями, и о ней ответственно было сообщено команде разработчиков. Поэтому прямо сейчас эксплуатация маловероятна. Более того, описанные выше технические сложности делают массовую эксплуатацию непрактичной. Десять тысяч попыток аутентификации при стандартных настройках OpenSSH займут 6–8 часов — и это на один сервер. Причем нужно знать, на какой версии Linux этот сервер работает. Если же у сервера есть какая-либо защита от перебора паролей и DDoS, то велика вероятность, что эти меры заблокируют атаку.

Несмотря на все это, целевая эксплуатация уязвимости CVE-2024-6387 вполне возможна. Терпеливые атакующие вполне могут провести разведку, а затем делать попытки с низкой частотой и с разных IP, и рано или поздно добиться успеха.

Как защититься от эксплуатации CVE-2024-6387

Уязвимости подвержены версии OpenSSH до 4.4p1 и версии с 8.5p1 по 9.7p1, работающие на glibc-Linux. Администраторы серверов на OpenBSD спят спокойно, а вот всем остальным необходимо обновить sshd до версии 9.8.

Если незамедлительное обновление по каким-то причинам невозможно, то в качестве временной меры можно установить тайм-аут входа равным нулю (LoginGraceTime=0 в sshd_config). Этот метод можно использовать и в случае, если на вашем устройстве невозможно обновление OpenSSH. Однако разработчики предупреждают, что это упрощает DDoS-атаку на сервер SSH.

Другая возможная компенсирующая мера — более строгое ограничение доступа к SSH, устанавливаемое при помощи межсетевых экранов и других инструментов сетевой безопасности.