Cisco: в ПО коммутаторов и маршрутизаторов компании присутствует критическая уязвимость в SSH-сервере из Erlang/OTP
Американский производитель сетевого оборудования Cisco подтвердил наличие критической уязвимости CVE-2025-32433 в ПО своих коммутаторов и маршрутизаторов в SSH-сервере из Erlang/OTP, позволяющей удалённое выполнение кода без аутентификации.
Примечательно, что, помимо сетевого оборудования Cisco, данная уязвимость затрагивает продукты компании Ericsson, а также различные IoT-системы, в которых применяется язык программирования Erlang.
Cisco подтвердила разработку патчей по ИБ программного обеспечения для устранения данной проблемы и настоятельно рекомендует пользователям установить патчи для Erlang/OTP версии 27.3.3, 26.2.5.11 или 25.3.2.20. В качестве временной меры до выпуска исправлений производитель советует ограничить доступ к SSH-порту уязвимых устройств, например, с помощью настроек брандмауэра. В компании добавили, что публичные эксплойты, использующие этот дефект, уже доступны.
Ранее специалисты по ИБ из Рурского университета в Бохуме (Германия) обнаружили в библиотеке ssh, входящей в состав SSH-сервера из Erlang/OTP, критическую уязвимость CVE-2025-32433, позволяющую удалённое выполнение кода без аутентификации на SSH-сервере, созданном с использованием уязвимой библиотеки. Эта уязвимость получила максимальные 10 баллов из 10 возможных по шкале оценки уязвимостей CVSS.
Решение Erlang/OTP (Open Telecom Platform, OTP) представляет собой фреймворк, содержащий набор библиотек, шаблонов проектирования для построения масштабируемых распределённых приложений на языке Erlang и инструментов, включая такие компоненты, как SSH-приложение для удалённого доступа.
Уязвимость CVE-2025-32433 затрагивает все устройства, на которых работает SSH-демон Erlang/OTP, а для её устранения пользователям рекомендуется оперативно обновиться до версий Erlang/OTP-27.3.3, OTP-26.2.5.11 и OTP-25.3.2.20. Проследить за устранением уязвимости в различных дистрибутивах можно на следующих страницах: Debian, Ubuntu, Fedora, SUSE/openSUSE, RHEL, Arch, FreeBSD.
«Проблема связана с недостатком при обработке SSH-сообщений, из-за чего атакующий получает возможность отправлять сообщения до прохождения аутентификации», — пояснено в списке рассылки Openwall.
Один из исследователей по ИБ подготовил рабочий эксплоит для выполнения кода на уязвимых SSH‑серверах Erlang/OTP. Примечательно, что, по словам исследователя, код был создан с использованием BB‑ассистентов GPT-4, Cursor и Sonnet на основе анализа изменения с исправлением уязвимости, включающего тест для проверки устранения проблемы.
Библиотека от проекта Erlang/OTP предоставляет готовые реализации клиента и сервера SSH и SFTP, поддерживающих протокол SSH 2.0. Отличить проблемные SSH‑серверы можно по выводу заголовка «SSH-2.0-Erlang/версия». SSH‑серверы на базе Erlang/OTP используются в специализированных системах, например на IoT‑ и устройствах для edge‑вычислений, а также в качестве отладочного инструмента — Erlang позволяет легко включить SSH‑сервер для удалённой отладки своих приложений (предполагается, что подобная отладочная возможность могла быть оставлена включённой во многих проектах, написанных на Erlang). Проблема также проявляется в инструментарии Elixir (реализован поверх Erlang) и во фреймворке Phoenix на его основе, но SSH‑сервер в Phoenix по умолчанию не принимает запросы из внешних сетей.
Уязвимость вызвана ошибкой в коде разбора сообщений, из‑за которой сообщения SSH_MSG_CHANNEL_REQUEST, допускающие выполнение команды «exec», обрабатывались на стадии до прохождения аутентификации. Пример кода из эксплоита:
command = 'file:write_file("/lab.txt", <<"pwned">>).' return ( b"\x62" # SSH_MSG_CHANNEL_REQUEST + struct.pack(">I", channel_id) + string_payload("exec") + b"\x01" # want_reply = true + string_payload(command) )
Профильные специалисты рекомендуют системным администраторам как можно скорее обновиться до исправленных версий Erlang/OTP, пока PoC не стали общедоступными, и уязвимость не начала применяться в массовых атаках. Если установка патчей по каким-то причинам невозможна, рекомендуется ограничить доступ к SSH только доверенными IP-адресами или временно отключить демон SSH.