Уязвимость в Net-SNMP, допускающая удалённое выполнение кода
В пакете Net-SNMP, реализующем протоколы SNMP v1, SNMP v2c и SNMP v3, выявлена уязвимость (CVE-2025-68615), позволяющая добиться удалённого выполнения кода на сервере, использующем сервис snmptrapd для приёма и обработки trap-сообщений от устройств. По умолчанию сервис принимает запросы на 162 UDP-порту и запускается с правами root. Проблеме присвоен критический уровень опасности (9.8 из 10). Атака может быть совершена без прохождения аутентификации.
Уязвимость вызвана некорректной проверкой размера OID (“trapOidLen >= 0” вместо “trapOidLen > 0”) перед копированием указанных в пакете данных в буфер фиксированного размера. Передача специально оформленных пакетов приводит к записи данных за границу буфера trapOid, что может быть эксплуатировано для выполнения кода атакующего с правами под которыми выполняется процесс snmptrapd. Уязвимость устранена в обновлениях Net-SNMP 5.9.5 и 5.10.pre2. В качестве дополнительной защиты рекомендуется заблокировать доступ из внешних сетей к UDP-порту 162 на межсетевом экране.
Дополнение: Уязвимость была добавлена при неудачной попытке исправить предыдущую проблему с переполнением буфера из-за некорректной проверки “trapOid[trapOidLen - 1] != 0”. Изначальный код “trapOid[trapOidLen - 1] != 0” присутствует в кодовой базе с 23 июня 2003 года, когда выполнялся рефакторинг файла snmptrapd_handlers.c.
В master-ветке исправление “> 0” уже откатили и заменили на универсальную проверку. Переполнения trapOid было успешно исправлено за три попытки:
- Первоначальное исправление:
if (trapOidLen >= 0 && trapOid[trapOidLen - 1] != 0) - Замена на проверку:
if (trapOidLen > 0 && trapOid[trapOidLen - 1] != 0) - Окончательное решение: универсальная проверка границ буфера
Что характерно, до этой уязвимости с trapOid были другие проблемы с записью за границу буфера.
Комментарии сообщества
Безопасность конфигурации SNMP
Пользователь 1.1: “Есть особо одаренные, что выставляют SNMP наружу?”
Ответ 2.7: “Снял с языка.”
Ответ 2.12: “бывают корпсети на десятки-сотни тысяч устройств.”
Ответ 3.17: “В корпсетях здорового человека существует отдельный административный VLAN для железяк. Из которого даже маршрута в остальные локальные сети если делать по уму нема, хочешь рулить - на рабочее место себе его отдельным планом вытащи и отдельным интерфейсом в него втыкайся.”
Ответ 4.22: “В распределённых корпсетях здорового человека еще существует IPACL и SNMPv3.”
Технические детали уязвимости
Пользователь 1.18 предоставил детальный анализ: “На самом деле там все намного интереснее. Прям TEH DRAMA ‘Сишники и Буфер’ в трех частях :)
Текущий фикс это попытка исправить buffer overflow [1]
- if (trapOid[trapOidLen - 1] != 0) {
- if (trapOidLen >= 0 && trapOid[trapOidLen - 1] != 0) {
А предыдущий код c trapOid[trapOidLen - 1] != 0 появился [2] в кодовой базе как минимум 22 года назад в Jun 23, 2003, когда выполнялся рефакторинг файла snmptrapd_handlers.c.
На ветке мастер исправление ‘> 0’ уже откатили и заменили [3] на универсальную проверку. Это переполнения trapOid было успешно исправлено всего за три попытки! Невероятный успех!
Впрочем, это не единственная проблема с trapOid [4]”
Обсуждение языков программирования
Пользователь 1.19: “Sbj написан c, perl, python. Переписать на rust, go, haskell не предлагаю. Однако, для новых следует задуматься или о других ЯП или найти тех, кто длину буфера проверяет каждый раз.”
Ответ 2.36: “Зачем?”
Ответ 3.43: “Хороший вопрос. Напр. чтобы неизвестно кто не выполнял произвольный код у тебя на серваке. Жаль не все это понимают.”
Ответ 4.53: “Дак нам не надо чтоб snmpd на расте в панику падал каждый раз при попытке выйти за границу буфера. Нам надо чтоб это корректно обрабатывалось и сервер продолжал работать.”
Критика процесса разработки
Пользователь 1.33: “> присутствует в кодовой базе с 23 июня 2003 года
Переполнения trapOid было успешно исправлено за три попытки
Что??? Ахаха! Серьезно?? Вот это ПОПЕДА!
Сишники прям доказывают насколько хорошо они пишут код. Всего три попытки понадобилось, чтобы разобраться как размер буфера считать)) Но главное что приложение не падает как у некоторых. Ну и позволяет выполнить произвольный код скорее всего с 2003 года.
Зато клованы будут рассказывать что ‘ано просто работает!!111’”
Ответ 2.54: “В-первых, ты процитировал какого-то баклана, который ничего не понимает. Во-вторых,без этой новости ты бы даже не узнал что в snmptrapd есть какое-то переполнение. В-третьих, не надо думать что все вокруг тупые идиоты, и только одни вы растовые хеллоуворлдщики - профи. Ты думаешь авторы сабжа не способны и не знают как проверить длину буфера в раст-стиле? Дак там была эта проверка с 2003г. И даже первые две попытки исправления сделали также как сделал бы раст.”
Заключение
Уязвимость CVE-2025-68615 в Net-SNMP демонстрирует классический пример ошибки проверки границ буфера, которая оставалась в коде более 22 лет. Критичность уязвимости (9.8/10) обусловлена сочетанием факторов: возможность удалённого выполнения кода, отсутствие необходимости аутентификации и выполнение службы snmptrapd с правами root по умолчанию.
Сообщество разделилось во мнениях: одни критикуют качество кода на C и предлагают переход на более безопасные языки программирования, другие указывают на реальные потребности корпоративных сетей и сложности миграции legacy-систем. Независимо от позиции, все согласны с необходимостью соблюдения базовых принципов безопасности: изоляция служебных протоколов, использование ACL и своевременное обновление программного обеспечения.
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64530-net-snmp
Ключевые слова: net-snmp, snmp
При перепечатке указание ссылки на opennet.ru обязательно