В пакете Net-SNMP, реализующем протоколы SNMP v1, SNMP v2c и SNMP v3, выявлена уязвимость (CVE-2025-68615), позволяющая добиться удалённого выполнения кода на сервере, использующем сервис snmptrapd для приёма и обработки trap-сообщений от устройств. По умолчанию сервис принимает запросы на 162 UDP-порту и запускается с правами root. Проблеме присвоен критический уровень опасности (9.8 из 10). Атака может быть совершена без прохождения аутентификации...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64530
Есть особо одаренные, что выставляют SNMP наружу?
Снял с языка.
> сервис принимает запросы на 162 UDP-порту и запускается с правами rootСтранно... Системдэшники говорят, что это только баш-портянки запускаются от рута...
>что выставляют SNMP наружубывают корпсети на десятки-сотни тысяч устройств.
> бывают корпсети на десятки-сотни тысяч устройств.В корпсетях здорового человека существует отдельный административный VLAN для железяк. Из которого даже маршрута в остальные локальные сети если делать по уму нема, хочешь рулить - на рабочее место себе его отдельным планом вытащи и отдельным интерфейсом в него втыкайся.
В распределённых корпсетях здорового человека еще существует IPACL и SNMPv3.
надо понимать что это дополнительная защита иначе говоря уменьшение плоскости атаки, но это не значит что злоумышленник не может эксплуатировать уязвимость, попав другим способом во внутрь контура корп сети.
Security? Not My Problem!
> Security? Not My Problem!именно так.. уязвимостей тут нет за ненадобностью, только фичи (документированные и не документированные)..
этот SNMP сам по себе всегда был дырой и им остается без всякой помощи от трапов
На самом деле там все намного интереснее.
Прям 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
> "Сишники и Буфер":D
Sbj написан c, perl, python. Переписать на rust, go, haskell не предлагаю. Однако, для новых следует задуматься или о других ЯП или найти тех, кто длину буфера проверяет каждый раз.
Зачем?
> Зачем?Хороший вопрос.
Напр. чтобы неизвестно кто не выполнял произвольный код у тебя на серваке.
Жаль не все это понимают.
Дак нам не надо чтоб snmpd на расте в панику падал каждый раз при попытке выйти за границу буфера. Нам надо чтоб это корректно обрабатывалось и сервер продолжал работать.
> Дак нам не надо чтоб snmpd на расте в панику падал каждый раз
> при попытке выйти за границу буфера.Каждый раз?))
Вообще должно хватить одного раза, чтобы скинуть логи разработчикам и они бы исправили проблему. Но для вас да... одного раза явно не хватит))> Нам надо чтоб это корректно обрабатывалось и сервер продолжал работать
... и выполнять произвольный код)
> ... и выполнять произвольный код)Ты случайно не пишешь хеллоувроты на расте? Иначе бы увидел "__корректно__ обрабатывалось и сервер продолжал работать"
Передача специально оформленных пакетов приводит к записи данных за границу буфера trapOid, что может быть эксплуатировано для выполнения кода
даёшь переход на процессоры гарвардской архитектуры!
> проверку выхода за границы массиваЭта проверка даже в древнем паскале уже была. Жамкаешь одну галочку - и если можно проверить статически - генерировалась compile-error, а если на внешние данные завязано - то вставлялась run-time проверка.
> присутствует в кодовой базе с 23 июня 2003 года
> Переполнения trapOid было успешно исправлено за три попыткиЧто??? Ахаха! Серьезно??
Вот это ПОПЕДА!Сишники прям доказывают насколько хорошо они пишут код.
Всего три попытки понадобилось, чтобы разобраться как размер буфера считать))
Но главное что приложение не падает как у некоторых.
Ну и позволяет выполнить произвольный код скорее всего с 2003 года.Зато клованы будут рассказывать что "ано просто работает!!111"
Чего там за это времени выполнили? Перечисляй.
> Чего там за это времени выполнили?Ты читать не умеешь? Написано же - "удалённого выполнения".
Причем не просто так, а правами root да еще и без прохождения аутентификации.
В общем все как тут любят))
В-первых, ты процитировал какого-то баклана, который ничего не понимает.Во-вторых,без этой новости ты бы даже не узнал что в snmptrapd есть какое-то переполнение.
В-третьих, не надо думать что все вокруг тупые идиоты, и только одни вы растовые хеллоуворлдщики - профи. Ты думаешь авторы сабжа не способны и не знают как проверить длину буфера в раст-стиле? Дак там была эта проверка с 2003г. И даже первые две попытки исправления сделали также как сделал бы раст.
> ты процитировал какого-то баклана, который ничего не понимает.Он привел ссылки на их гитхаб. А ты только газифицируешь лужу.
> без этой новости ты бы даже не узнал что в snmptrapd есть какое-то переполнение.
Конечно! И это основная проблема.
> не надо думать что все вокруг тупые иdиoты,
Да, конечно. Просто 20+ лет не могут разобраться как размер буфера считать. И смогли только с третьего раза и после CVE 9.8 из 10. Это уже что-то большее чем иdиoты)))
> и только одни вы растовые хеллоуворлдщики - профи
Ахаха, а раст тут при чем, если проблема в сишечке?))
> Ты думаешь авторы сабжа не способны и не знают как проверить длину буфера в раст-стиле?
Да, не способны и они это отлично показали.
> Дак там была эта проверка с 2003г.
Не было, там была корявая проверка, которую правили еще несколько раз.
> И даже первые две попытки исправления сделали также как сделал бы раст.
Что?? Ты уже нажрался на НГ? Иди проспись и пиши после праздников!
> Да, не способны и они это отлично показали.Ты реально не понимаешь, что растаманы точно так же не умеют в память? Ведь именно поэтому они и пользуются растом.
> Не было, там была корявая проверка, которую правили еще несколько раз.
Ну покажи как бы ты на расте это устранил если ты такой умный.
Там много стандартов этого С уже вышло. Подскажите, а неужели нет там механизма, чтобы пусть с уменьшением производительности, но не допускать выполнения кода при выходе за массив?
Перейти на Zig
перейти на паскаль. Там есть проверки, как времени компиляции, так и при выполнении.
*не глядя* переполнение буфера? опять некачественные программисты?
Ну это примерно как скрипка в руках скрипача. Ну вот не бывает скрипок, которая не позволяет фальшивить. Сишка это скрипка, а раст это детская игрушка, где нажимаешь кнопку, а она говорит: "корова говорит муууу" чтоб случайно не ту ноту не взял.
> раст это детская игрушка, где нажимаешь кнопку, а она говорит: "корова говорит муууу"Пожалуй, самое точное описание языка.
> Ну вот не бывает скрипок, которая не позволяет фальшивить.Но про скрипки, которые отстреливают ноги или отрывают пальцы что-то тоже не слышно.
> Сишка это скрипка
Сишка это палка-копалка. Или бревно по которому можно фигачить другой палкой и кричать унга-бунга, если уже использовать музыкальные сравнения. Заодно можно ее этой палкой попасть себе по ноге. Или по голове соседа, это уже как повезет.
> Сишка это палка-копалка.Перегибаешь ... впрочем это от незнания ;)
Да - "первоСи"(С) - был конечно элементарным по сравнению с тем что он сейчас, по его листингу прямо в уме "раскручивался" MACRO-11, кто на педепе\ваХ!\СМ работал - подтвердят.
Но и он ("первоСи") для своих то времён вот прямо палкой копалкой уже не был. Для этого были ассемблеры.... Короче - скорее качественный, стандартный шанцевый инструмент :)
Кто знает что входило в комплект - тот поймёт, а кто не знает - тот салага и в СА не служил! :-р :))Инструмент, которым - таки да! можно! и Чёрное-пречёрное море выкопать ;) Но зачем!?!?!? 8-о
Си __хорош__ для коры ОС, для драйверов, для кодеков, для коры крипты, для лютого байтодроча и бутстрапа диковинного железа, и ___вот_это_вот_всё___ (С)...
Для всего остального - есть всё остальное!(С) :)
Тут чтобы не начинать флейм на терабайт траффика - без имен. Каждый пользует что ему зашло в этот отрезок времени. Есть _всё_ и на _любой_ вкус, разной степени упоротости и качества, на любой вкус и бюджет.
PS: С Наступающим Новым Годом РФ! :-)
> Перегибаешь ... впрочем это от незнания ;)Или от знания и вьетнамских флешбеков после исправления кода после "настоящих сишников" 😉
> Да - "первоСи"(С) - был конечно элементарным по сравнению с тем что он сейчас,
Неужели туда добавили type String? 🙀
> Но и он ("первоСи") для своих то времён вот прямо палкой копалкой уже не был. Для этого были ассемблеры.
Ассемблер это когда ты роешь руками)
> ... Короче - скорее качественный, стандартный шанцевый инструмент :)
Хаха, ну с "качественным" ты загнул.
> Но зачем!?!?!? 8-о
Логично.
Это как хвалить перо и чернильницу. Да чтобы повы###ться подойдет, для реальной работы - уже устарело.
Но да, как и уаз, можно выдрать перо из почти любой курицы, а что-то красящее человек выдает в больших количествах.> Си __хорош__ для коры ОС, для драйверов, для кодеков, для коры крипты,
> для лютого байтодроча и бутстрапа диковинного железа, и ___вот_это_вот_всё___ (С)...В итоге "кора ОС" дырявая, драйвера дырявые, криптобиблиотеки ... тоже внезапно дырявые.
> Каждый пользует что ему зашло в этот отрезок времени.
Так пусть пользуются.
Но сколько вскруракеков было, когда начали раст в ядро добавлять?
Хотя казалось бы, вы простые пользаки, просто закрыли варежки и не мешайте тем, кто ядро делает.> PS: С Наступающим
И тебя тоже)
Кто в теме, можете подсказать?Ошибка-то тупая. Я точно такую не допустил бы (не троллю). Но при этом потратил бы кучу времени на перепроверку кода в результате рефакторинга, чтоб убедиться, что проблем нет.
Почему её допустили эти программисты?
1. Не слишком умные?
2. Не слишком заморачиваются при написании кода?
3. Работодатель не даёт достаточно времени на проверки?Я понимаю, когда причины ошибки разбросаны по разным участкам кода, но здесь же прямо в одном выражении понятно, что что-то не так.
Спрашиваю у сишников или причастных, кто в теме. Сам программирую на других технологиях, на C иногда пишу для души.
4. Ошибка была нужна, иначе как объяснить исправление только с третьего пинка?
> Уязвимость была добавлена при неудачной попытке исправить предыдущую проблему5. Просто устали.
> Спрашиваю у сишников или причастных, кто в темеПросто сишники не умеют писать код. Даже самые крутые лажают.
Ну а сам си компиляет любую хню, которую выдавил погромист.
> сишники не умеют писать кодНа чём писали первый компилятор раста? Ведь они с твоих слов не умели...
> На чём писали первый компилятор раста?На OCaml написали первый, а что?
А второй на с++. Невозможно написать нормальный оптимизирующий компилятор на сишечке.
Вот и llvm, и gcc перешли на плюсы.
> Невозможно написать нормальный оптимизирующий компилятор на сишечке.До 2008г как-то вот gcc существовал на чистой сишке и был оптимизирующим. Вы просто пересказываете одну и ту же байку из раза в раз про то, что на сишке что-то сделать невозможно. Но вы, я смотрю, скорее всего пишете хеллоувроты на расте, иначе бы почитали о причинах перехода с Си на С++ в gcc. Дело там вообще не в оптимизирующем компиляторе.
> До 2008г как-то вот gcc существовал на чистой сишке и был оптимизирующим.Вы специально пропустили слово "нормальный" в оригинальной цитате?
> Вы просто пересказываете одну и ту же байку из раза в
> раз про то, что на сишке что-то сделать невозможно.Можно до определенного размера проекта. А потом усилия на борьбу с "простотой" сишки начинают занимать слишком много внимания разработчиков.
> Но вы, я смотрю, скорее всего пишете хеллоувроты на расте,
Ваш хрустальный шар показывает какую-то фигню.
> почитали о причинах перехода с Си на С++ в gcc.
C++ supports cleaner code in several significant cases.
C++ makes it easier to write cleaner interfaces by
making it harder to break interface boundaries.
C++ never requires uglier code.
C++ is not a panacea but it is an improvement.
C++ permits reference counting smart pointers
Sometimes C++ is faster (e.g., STL functions)Прям из первоисточника - презентация Ian Lance Taylor за 2008 год.
А теперь с удовольствием послушаем вашу версию произошедшего))
> Прям из первоисточника - презентация Ian Lance Taylor за 2008 год.
> А теперь с удовольствием послушаем вашу версию произошедшего))Ну дак все так и есть, что спорить то если сам автор инициативы так говорит. Только я не вижу в списке причин - на сишке невозможно написать _нормальный_ оптимизирующий компилятор. Был даже где-то видео-доклад ЕМНИП где из всех этих причин он выделил основные две - конструкторы/деструкторы и STL с его контейнерами. Т.е. люди просто захотели отказаться от своих собственных костылей на Си, в которых они сделали свои list'ы, b-tree и тд. Но это не значит что до начала переписывания GCC не существовал и/или был не оптимизирующим. И уж тем более не значит, что это всё нельзя сделать без C++.
> Только я не вижу в списке причин - на сишке невозможно написать _нормальный_ оптимизирующий компилятор.Потому что ты его просто не напишешь, а завязнешь в нагромождении костылей))
> из всех этих причин он выделил основные две - конструкторы/деструкторы
> и STL с его контейнерами.Да! Без RAII и контейнеров очень сложно писать большой проект. А GGC сильно разросся.
И любой нормальный язык должен это содержать, а не предлагать разработчику велосипедить костыли заново.> Т.е. люди просто захотели отказаться от своих собственных костылей на Си,
У них еще на си была самописная сборка мусора.
> Но это не значит что до начала переписывания GCC не существовал
> и/или был не оптимизирующим.Существовал. Но был намного проще чем сейчас. И оптимизации были существенно проще.
> И уж тем более не значит, что это всё нельзя сделать без C++.
А вот это уже нужно доказывать. Пока что все современные открытые оптимизирующие компиляторы на си++, а на сишке остались разные древние поделия.
> И любой нормальный язык должен это содержать, а не предлагать разработчику велосипедить костыли заново.Сомнительно, но... нет, не окей. Вот в C++ есть ключевое слово new и operator new(), которые аллоцируют память динамически в куче. Причем они не часть стандартной библиотеки, а часть самого языка... его семантики, если так можно сказать. Дак вот нафига оно нужно, если я пишу загрузчик MBR, который запускается напрямую BIOS'ом и где нет никакой ОС и тем более стандартной библиотеки чтоб аллоцировать память динамически чепез malloc()? Зачем там new, если его юзать невозможно? Не логично ли было сделать чтоб new был частью библы, а не частью самого языка?
Вот и с этими всеми STL, RAII и тд то же самое, но уже в контексте стандартной библиотеки. Не нужно это всё _именно_ в стандартной библиотеке, тем более в сишной.
Авторам gcc, конечно же виднее, как им писать их компилятор, но лично я не считаю что свой сборщик мусора, свои контейнеры, списки, массивы, деревья - это костыли. Потому что это все идет в общем дистрибутиве исходников gcc, а не из внешних библиотек, которые надо было бы устанавливать.
>Не логично ли было сделать чтоб new был частью библы, а не частью самого языка?Нет, не логично. Обычная библиотечная функция (malloc) не может сама по себе встроиться в цепочку "выделить память > вызвать нужный конструктор > вернуть корректно типизированный указатель" без участия компилятора и специального синтаксиса.
>лично я не считаю что свой сборщик мусора, свои контейнеры, списки, массивы, деревья - это костылиМного вы компиляторов написали? Это костыли, потому что часто такие самописные поделия не учитывают какие-то инварианты (ввиду ограниченности опыта пишущих), плохо оптимизированы (неэффективны), их тяжело сопровождать.