The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в Net-SNMP, допускающая удалённое выполнение кода

30.12.2025 10:59

В пакете 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 было успешно исправлено за три попытки: 1, 2, 3. Что характерно, до этой уязвимости с trapOid были другие проблемы с записью за границу буфера.

  1. Главная ссылка к новости (https://www.zerodayinitiative....)
  2. OpenNews: Обновление голосовых данных Mozilla Common Voice 20
  3. OpenNews: В Net-SNMP нашли возможность записи в "read-only" ресурс.
  4. OpenNews: Возможность обхода SNMPv3 аутентификации в Net-SNMP, Cisco и Juniper
  5. OpenNews: Релиз пакета Net-SNMP 5.6
  6. OpenNews: DoS-уязвимость в Net-SNMP
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/64530-net-snmp
Ключевые слова: net-snmp, snmp
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (48) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Грудная Жаба (?), 11:21, 30/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Есть особо одаренные, что выставляют SNMP наружу?
     
     
  • 2.7, Аноним (7), 11:58, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Снял с языка.
     
     
  • 3.47, Аноним (47), 23:38, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > сервис принимает запросы на 162 UDP-порту и запускается с правами root

    Странно... Системдэшники говорят, что это только баш-портянки запускаются от рута...

     
  • 2.12, Анонисссм (?), 12:12, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >что выставляют SNMP наружу

    бывают корпсети на десятки-сотни тысяч устройств.

     
     
  • 3.17, HyC (?), 13:12, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > бывают корпсети на десятки-сотни тысяч устройств.

    В корпсетях здорового человека существует отдельный административный VLAN для железяк. Из которого даже маршрута в остальные локальные сети если делать по уму нема, хочешь рулить - на рабочее место себе его отдельным планом вытащи и отдельным интерфейсом в него втыкайся.

     
     
  • 4.22, Аноним (22), 15:55, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В распределённых корпсетях здорового человека еще существует  IPACL и SNMPv3.
     
  • 2.52, анонимно (?), 02:18, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    надо понимать что это дополнительная защита иначе говоря уменьшение плоскости атаки, но это не значит что злоумышленник не может эксплуатировать уязвимость, попав другим способом во внутрь контура корп сети.
     

  • 1.3, Я (??), 11:28, 30/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Security? Not My Problem!
     
     
  • 2.16, крокодил мимо.. (-), 13:03, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Security? Not My Problem!

    именно так.. уязвимостей тут нет за ненадобностью, только фичи (документированные и не документированные)..

     

  • 1.14, Аноним (14), 12:59, 30/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    этот SNMP сам по себе всегда был дырой и им остается без всякой помощи от трапов
     
  • 1.18, Анонимусс (-), 13:17, 30/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    На самом деле там все намного интереснее.
    Прям 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] github.com/net-snmp/net-snmp/commit/ce1c9d4455a405d2ed8a2ac7b26b778e008e86d5

    [2] github.com/net-snmp/net-snmp/commit/7236e8414ad463a0a5a1b699ad9aa2a2bf1b9342#diff-0ab05b8a4ba86a8f21ecbdc200ff67cfd4edef5d8160c161b6eab64646fe31cdR93

    [3] github.com/net-snmp/net-snmp/commit/4a201ac239d2cedff32a9205d389fdb523487878

    [4] github.com/net-snmp/net-snmp/commit/ce1c9d4455a405d2ed8a2ac7b26b778e008e86d5

     
     
  • 2.56, Аноним (56), 08:30, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > "Сишники и Буфер"

    :D

     

  • 1.19, onemetr (?), 14:08, 30/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Sbj написан c, perl, python. Переписать на rust, go, haskell не предлагаю. Однако, для новых следует задуматься или о других ЯП или найти тех, кто длину буфера проверяет каждый раз.
     
     
  • 2.36, Аноним (36), 20:43, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем?
     
     
  • 3.43, Аноним (-), 22:36, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем?

    Хороший вопрос.
    Напр. чтобы неизвестно кто не выполнял произвольный код у тебя на серваке.
    Жаль не все это понимают.

     
     
  • 4.53, Аноним (53), 03:03, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дак нам не надо чтоб snmpd на расте в панику падал каждый раз при попытке выйти за границу буфера. Нам надо чтоб это корректно обрабатывалось и сервер продолжал работать.
     
     
  • 5.62, Аноним (-), 11:43, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Дак нам не надо чтоб snmpd на расте в панику падал каждый раз
    > при попытке выйти за границу буфера.

    Каждый раз?))
    Вообще должно хватить одного раза, чтобы скинуть логи разработчикам и они бы исправили проблему. Но для вас да... одного раза явно не хватит))

    > Нам надо чтоб это корректно обрабатывалось и сервер продолжал работать

    ... и выполнять произвольный код)

     
     
  • 6.66, Аноним (53), 13:39, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > ... и выполнять произвольный код)

    Ты случайно не пишешь хеллоувроты на расте? Иначе бы увидел "__корректно__ обрабатывалось и сервер продолжал работать"

     

  • 1.24, онанист (?), 16:49, 30/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/

    Передача специально оформленных пакетов приводит к записи данных за границу буфера trapOid, что может быть эксплуатировано для выполнения кода


    даёшь переход на процессоры гарвардской архитектуры!

     
     
  • 2.49, Аноним (47), 23:47, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > проверку выхода за границы массива

    Эта проверка даже в древнем паскале уже была. Жамкаешь одну галочку - и если можно проверить статически - генерировалась compile-error, а если на внешние данные завязано - то вставлялась run-time проверка.

     

  • 1.33, Аноним (-), 19:53, 30/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > присутствует в кодовой базе с 23 июня 2003 года
    > Переполнения trapOid было успешно исправлено за три попытки

    Что??? Ахаха! Серьезно??
    Вот это ПОПЕДА!

    Сишники прям доказывают насколько хорошо они пишут код.
    Всего три попытки понадобилось, чтобы разобраться как размер буфера считать))
    Но главное что приложение не падает как у некоторых.
    Ну и позволяет выполнить произвольный код скорее всего с 2003 года.

    Зато клованы будут рассказывать что "ано просто работает!!111"

     
     
  • 2.35, Аноним (36), 20:42, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Чего там за это времени выполнили? Перечисляй.
     
     
  • 3.46, Аноним (-), 23:05, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Чего там за это времени выполнили?

    Ты читать не умеешь? Написано же - "удалённого выполнения".
    Причем не просто так, а правами root да еще и без прохождения аутентификации.
    В общем все как тут любят))


     
  • 2.54, Аноним (53), 03:15, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В-первых, ты процитировал какого-то баклана, который ничего не понимает.

    Во-вторых,без этой новости ты бы даже не узнал что в snmptrapd есть какое-то переполнение.

    В-третьих, не надо думать что все вокруг тупые идиоты, и только одни вы растовые хеллоуворлдщики - профи. Ты думаешь авторы сабжа не способны и не знают как проверить длину буфера в раст-стиле? Дак там была эта проверка с 2003г. И даже первые две попытки исправления сделали также как сделал бы раст.

     
     
  • 3.61, Аноним (-), 11:26, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Он привел ссылки на их гитхаб А ты только газифицируешь лужу Конечно И это ос... большой текст свёрнут, показать
     
     
  • 4.65, Аноним (53), 13:38, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Да, не способны и они это отлично показали.

    Ты реально не понимаешь, что растаманы точно так же не умеют в память? Ведь именно поэтому они и пользуются растом.

    > Не было, там была корявая проверка, которую правили еще несколько раз.

    Ну покажи как бы ты на расте это устранил если ты такой умный.

     

  • 1.39, Аноним (39), 21:46, 30/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Там много стандартов этого С уже вышло. Подскажите, а неужели нет там механизма, чтобы пусть с уменьшением производительности, но не допускать выполнения кода при выходе за массив?
     
     
  • 2.40, Аноним (40), 21:49, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Перейти на Zig
     
  • 2.50, Аноним (47), 23:49, 30/12/2025 [^] [^^] [^^^] [ответить]  
  • +2 +/
    перейти на паскаль. Там есть проверки, как времени компиляции, так и при выполнении.
     

  • 1.51, Аноним (51), 02:14, 31/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    *не глядя* переполнение буфера? опять некачественные программисты?
     
     
  • 2.55, Аноним (53), 03:19, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это примерно как скрипка в руках скрипача. Ну вот не бывает скрипок, которая не позволяет фальшивить. Сишка это скрипка, а раст это детская игрушка, где нажимаешь кнопку, а она говорит: "корова говорит муууу" чтоб случайно не ту ноту не взял.
     
     
  • 3.58, Аноним (47), 08:50, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > раст это детская игрушка, где нажимаешь кнопку, а она говорит: "корова говорит муууу"

    Пожалуй, самое точное описание языка.

     
  • 3.64, Аноним (-), 12:20, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну вот не бывает скрипок, которая не позволяет фальшивить.

    Но про скрипки, которые отстреливают ноги или отрывают пальцы что-то тоже не слышно.

    > Сишка это скрипка

    Сишка это палка-копалка. Или бревно по которому можно фигачить другой палкой и кричать унга-бунга, если уже использовать музыкальные сравнения. Заодно можно ее этой палкой попасть себе по ноге. Или по голове соседа, это уже как повезет.

     
     
  • 4.75, _ (??), 20:06, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Сишка это палка-копалка.

    Перегибаешь ... впрочем это от незнания ;)
    Да - "первоСи"(С) - был конечно элементарным по сравнению с тем что он сейчас, по его листингу прямо в уме "раскручивался" MACRO-11, кто на педепе\ваХ!\СМ работал - подтвердят.
    Но и он ("первоСи") для своих то времён вот прямо палкой копалкой уже не был. Для этого были ассемблеры.

    ... Короче - скорее качественный, стандартный шанцевый инструмент :)
    Кто знает что входило в комплект - тот поймёт, а кто не знает - тот салага и в СА не служил! :-р  :))

    Инструмент, которым - таки да! можно! и Чёрное-пречёрное море выкопать ;)  Но зачем!?!?!? 8-о

    Си __хорош__ для коры ОС, для драйверов, для кодеков, для коры крипты, для лютого байтодроча и бутстрапа диковинного железа, и ___вот_это_вот_всё___ (С)...

    Для всего остального - есть всё остальное!(С) :)

    Тут чтобы не начинать флейм на терабайт траффика - без имен. Каждый пользует что ему зашло в этот отрезок времени. Есть _всё_ и на _любой_ вкус, разной степени упоротости и качества, на любой вкус и бюджет.


    PS: С Наступающим Новым Годом РФ! :-)

     
     
  • 5.77, Аноним (-), 22:52, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Или от знания и вьетнамских флешбеков после исправления кода после настоящих си... большой текст свёрнут, показать
     

  • 1.57, Аноним (56), 08:37, 31/12/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто в теме, можете подсказать?

    Ошибка-то тупая. Я точно такую не допустил бы (не троллю). Но при этом потратил бы кучу времени на перепроверку кода в результате рефакторинга, чтоб убедиться, что проблем нет.

    Почему её допустили эти программисты?
    1. Не слишком умные?
    2. Не слишком заморачиваются при написании кода?
    3. Работодатель не даёт достаточно времени на проверки?

    Я понимаю, когда причины ошибки разбросаны по разным участкам кода, но здесь же прямо в одном выражении понятно, что что-то не так.

    Спрашиваю у сишников или причастных, кто в теме. Сам программирую на других технологиях, на C иногда пишу для души.

     
     
  • 2.59, Аноним (47), 08:51, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    4. Ошибка была нужна, иначе как объяснить исправление только с третьего пинка?
     
  • 2.60, Аноним (47), 08:54, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Уязвимость была добавлена при неудачной попытке исправить предыдущую проблему

    5. Просто устали.

     
  • 2.63, Аноним (-), 11:45, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Спрашиваю у сишников или причастных, кто в теме

    Просто сишники не умеют писать код. Даже самые крутые лажают.
    Ну а сам си компиляет любую хню, которую выдавил погромист.

     
     
  • 3.68, Аноним (47), 14:19, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > сишники не умеют писать код

    На чём писали первый компилятор раста? Ведь они с твоих слов не умели...

     
     
  • 4.69, Аноним (-), 15:03, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > На чём писали первый компилятор раста?

    На OCaml написали первый, а что?

    А второй на с++. Невозможно написать нормальный оптимизирующий компилятор на сишечке.
    Вот и llvm, и gcc перешли на плюсы.

     
     
  • 5.70, Аноним (53), 15:20, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Невозможно написать нормальный оптимизирующий компилятор на сишечке.

    До 2008г как-то вот gcc существовал на чистой сишке и был оптимизирующим. Вы просто пересказываете одну и ту же байку из раза в раз про то, что на сишке что-то сделать невозможно. Но вы, я смотрю, скорее всего пишете хеллоувроты на расте, иначе бы почитали о причинах перехода с Си на С++ в gcc. Дело там вообще не в оптимизирующем компиляторе.

     
     
  • 6.71, Аноним (-), 16:27, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вы специально пропустили слово нормальный в оригинальной цитате Можно до опре... большой текст свёрнут, показать
     
     
  • 7.72, Аноним (53), 16:47, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Прям из первоисточника - презентация Ian Lance Taylor за 2008 год.
    > А теперь с удовольствием послушаем вашу версию произошедшего))

    Ну дак все так и есть, что спорить то если сам автор инициативы так говорит. Только я не вижу в списке причин - на сишке невозможно написать _нормальный_ оптимизирующий компилятор. Был даже где-то видео-доклад ЕМНИП где из всех этих причин он выделил основные две - конструкторы/деструкторы и STL с его контейнерами. Т.е. люди просто захотели отказаться от своих собственных костылей на Си, в которых они сделали свои list'ы, b-tree и тд. Но это не значит что до начала переписывания GCC не существовал и/или был не оптимизирующим. И уж тем более не значит, что это всё нельзя сделать без C++.

     
     
  • 8.73, Аноним (-), 16:58, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что ты его просто не напишешь, а завязнешь в нагромождении костылей Да ... большой текст свёрнут, показать
     
     
  • 9.74, Аноним (53), 17:28, 31/12/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Сомнительно, но нет, не окей Вот в C есть ключевое слово new и operator ne... большой текст свёрнут, показать
     
     
  • 10.78, Прохожий (??), 12:32, 01/01/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, не логично Обычная библиотечная функция malloc не может сама по себе вст... текст свёрнут, показать
     
  • 10.79, Прохожий (??), 12:36, 01/01/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Много вы компиляторов написали Это костыли, потому что часто такие самописные п... текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру