Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
Сообщение от opennews (?), 30-Дек-25, 11:21
В пакете Net-SNMP, реализующем протоколы SNMP v1, SNMP v2c и SNMP v3, выявлена уязвимость (CVE-2025-68615), позволяющая добиться удалённого выполнения кода на сервере, использующем сервис snmptrapd для приёма и обработки trap-сообщений от устройств. По умолчанию сервис принимает запросы на 162 UDP-порту и запускается с правами root. Проблеме присвоен критический уровень опасности (9.8 из 10). Атака может быть совершена без прохождения аутентификации... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64530
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+4 +/–
Сообщение от Грудная Жаба (?), 30-Дек-25, 11:21
Есть особо одаренные, что выставляют SNMP наружу?
Ответить | Правка | Наверх | Cообщить модератору

	7. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
	Сообщение от Аноним (7), 30-Дек-25, 11:58
	Снял с языка.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	–3 +/–
	Сообщение от Аноним (47), 30-Дек-25, 23:38
	> сервис принимает запросы на 162 UDP-порту и запускается с правами root Странно... Системдэшники говорят, что это только баш-портянки запускаются от рута...
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+4 +/–
	Сообщение от Анонисссм (?), 30-Дек-25, 12:12
	>что выставляют SNMP наружу бывают корпсети на десятки-сотни тысяч устройств.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	17. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+2 +/–
	Сообщение от HyC (?), 30-Дек-25, 13:12
	> бывают корпсети на десятки-сотни тысяч устройств. В корпсетях здорового человека существует отдельный административный VLAN для железяк. Из которого даже маршрута в остальные локальные сети если делать по уму нема, хочешь рулить - на рабочее место себе его отдельным планом вытащи и отдельным интерфейсом в него втыкайся.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (22), 30-Дек-25, 15:55
	В распределённых корпсетях здорового человека еще существует  IPACL и SNMPv3.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от анонимно (?), 31-Дек-25, 02:18
	надо понимать что это дополнительная защита иначе говоря уменьшение плоскости атаки, но это не значит что злоумышленник не может эксплуатировать уязвимость, попав другим способом во внутрь контура корп сети.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+3 +/–
Сообщение от Я (??), 30-Дек-25, 11:28
Security? Not My Problem!
Ответить | Правка | Наверх | Cообщить модератору

	16. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
	Сообщение от крокодил мимо.. (-), 30-Дек-25, 13:03
	> Security? Not My Problem! именно так.. уязвимостей тут нет за ненадобностью, только фичи (документированные и не документированные)..
	Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	–1 +/–
Сообщение от Аноним (14), 30-Дек-25, 12:59
этот SNMP сам по себе всегда был дырой и им остается без всякой помощи от трапов
Ответить | Правка | Наверх | Cообщить модератору

18. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+6 +/–
Сообщение от Анонимусс (-), 30-Дек-25, 13:17
На самом деле там все намного интереснее. Прям 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
Ответить | Правка | Наверх | Cообщить модератору

	56. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (56), 31-Дек-25, 08:30
	> "Сишники и Буфер" :D
	Ответить | Правка | Наверх | Cообщить модератору

19. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
Сообщение от onemetr (?), 30-Дек-25, 14:08
Sbj написан c, perl, python. Переписать на rust, go, haskell не предлагаю. Однако, для новых следует задуматься или о других ЯП или найти тех, кто длину буфера проверяет каждый раз.
Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (36), 30-Дек-25, 20:43
	Зачем?
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (-), 30-Дек-25, 22:36
	> Зачем? Хороший вопрос. Напр. чтобы неизвестно кто не выполнял произвольный код у тебя на серваке. Жаль не все это понимают.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	–1 +/–
	Сообщение от Аноним (53), 31-Дек-25, 03:03
	Дак нам не надо чтоб snmpd на расте в панику падал каждый раз при попытке выйти за границу буфера. Нам надо чтоб это корректно обрабатывалось и сервер продолжал работать.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (-), 31-Дек-25, 11:43
	> Дак нам не надо чтоб snmpd на расте в панику падал каждый раз > при попытке выйти за границу буфера. Каждый раз?)) Вообще должно хватить одного раза, чтобы скинуть логи разработчикам и они бы исправили проблему. Но для вас да... одного раза явно не хватит)) > Нам надо чтоб это корректно обрабатывалось и сервер продолжал работать ... и выполнять произвольный код)
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (53), 31-Дек-25, 13:39
	> ... и выполнять произвольный код) Ты случайно не пишешь хеллоувроты на расте? Иначе бы увидел "__корректно__ обрабатывалось и сервер продолжал работать"
	Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
Сообщение от онанист (?), 30-Дек-25, 16:49
Передача специально оформленных пакетов приводит к записи данных за границу буфера trapOid, что может быть эксплуатировано для выполнения кода даёшь переход на процессоры гарвардской архитектуры!
Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (47), 30-Дек-25, 23:47
	> проверку выхода за границы массива Эта проверка даже в древнем паскале уже была. Жамкаешь одну галочку - и если можно проверить статически - генерировалась compile-error, а если на внешние данные завязано - то вставлялась run-time проверка.
	Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
Сообщение от Аноним (-), 30-Дек-25, 19:53
> присутствует в кодовой базе с 23 июня 2003 года > Переполнения trapOid было успешно исправлено за три попытки Что??? Ахаха! Серьезно?? Вот это ПОПЕДА! Сишники прям доказывают насколько хорошо они пишут код. Всего три попытки понадобилось, чтобы разобраться как размер буфера считать)) Но главное что приложение не падает как у некоторых. Ну и позволяет выполнить произвольный код скорее всего с 2003 года. Зато клованы будут рассказывать что "ано просто работает!!111"
Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	–1 +/–
	Сообщение от Аноним (36), 30-Дек-25, 20:42
	Чего там за это времени выполнили? Перечисляй.
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+2 +/–
	Сообщение от Аноним (-), 30-Дек-25, 23:05
	> Чего там за это времени выполнили? Ты читать не умеешь? Написано же - "удалённого выполнения". Причем не просто так, а правами root да еще и без прохождения аутентификации. В общем все как тут любят))
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	–1 +/–
	Сообщение от Аноним (53), 31-Дек-25, 03:15
	В-первых, ты процитировал какого-то баклана, который ничего не понимает. Во-вторых,без этой новости ты бы даже не узнал что в snmptrapd есть какое-то переполнение. В-третьих, не надо думать что все вокруг тупые идиоты, и только одни вы растовые хеллоуворлдщики - профи. Ты думаешь авторы сабжа не способны и не знают как проверить длину буфера в раст-стиле? Дак там была эта проверка с 2003г. И даже первые две попытки исправления сделали также как сделал бы раст.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	61. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
	Сообщение от Аноним (-), 31-Дек-25, 11:26
	> ты процитировал какого-то баклана, который ничего не понимает. Он привел ссылки на их гитхаб. А ты только газифицируешь лужу. > без этой новости ты бы даже не узнал что в snmptrapd есть какое-то переполнение. Конечно! И это основная проблема. > не надо думать что все вокруг тупые иdиoты, Да, конечно. Просто 20+ лет не могут разобраться как размер буфера считать. И смогли только с третьего раза и после CVE 9.8 из 10. Это уже что-то большее чем иdиoты))) > и только одни вы растовые хеллоуворлдщики - профи Ахаха, а раст тут при чем, если проблема в сишечке?)) > Ты думаешь авторы сабжа не способны и не знают как проверить длину буфера в раст-стиле? Да, не способны и они это отлично показали. > Дак там была эта проверка с 2003г. Не было, там была корявая проверка, которую правили еще несколько раз. > И даже первые две попытки исправления сделали также как сделал бы раст. Что?? Ты уже нажрался на НГ? Иди проспись и пиши после праздников!
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	–1 +/–
	Сообщение от Аноним (53), 31-Дек-25, 13:38
	> Да, не способны и они это отлично показали. Ты реально не понимаешь, что растаманы точно так же не умеют в память? Ведь именно поэтому они и пользуются растом. > Не было, там была корявая проверка, которую правили еще несколько раз. Ну покажи как бы ты на расте это устранил если ты такой умный.
	Ответить | Правка | Наверх | Cообщить модератору

39. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
Сообщение от Аноним (39), 30-Дек-25, 21:46
Там много стандартов этого С уже вышло. Подскажите, а неужели нет там механизма, чтобы пусть с уменьшением производительности, но не допускать выполнения кода при выходе за массив?
Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (40), 30-Дек-25, 21:49
	Перейти на Zig
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+2 +/–
	Сообщение от Аноним (47), 30-Дек-25, 23:49
	перейти на паскаль. Там есть проверки, как времени компиляции, так и при выполнении.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

51. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
Сообщение от Аноним (51), 31-Дек-25, 02:14
*не глядя* переполнение буфера? опять некачественные программисты?
Ответить | Правка | Наверх | Cообщить модератору

	55. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (53), 31-Дек-25, 03:19
	Ну это примерно как скрипка в руках скрипача. Ну вот не бывает скрипок, которая не позволяет фальшивить. Сишка это скрипка, а раст это детская игрушка, где нажимаешь кнопку, а она говорит: "корова говорит муууу" чтоб случайно не ту ноту не взял.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
	Сообщение от Аноним (47), 31-Дек-25, 08:50
	> раст это детская игрушка, где нажимаешь кнопку, а она говорит: "корова говорит муууу" Пожалуй, самое точное описание языка.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
	Сообщение от Аноним (-), 31-Дек-25, 12:20
	> Ну вот не бывает скрипок, которая не позволяет фальшивить. Но про скрипки, которые отстреливают ноги или отрывают пальцы что-то тоже не слышно. > Сишка это скрипка Сишка это палка-копалка. Или бревно по которому можно фигачить другой палкой и кричать унга-бунга, если уже использовать музыкальные сравнения. Заодно можно ее этой палкой попасть себе по ноге. Или по голове соседа, это уже как повезет.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	75. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от _ (??), 31-Дек-25, 20:06
	> Сишка это палка-копалка. Перегибаешь ... впрочем это от незнания ;) Да - "первоСи"(С) - был конечно элементарным по сравнению с тем что он сейчас, по его листингу прямо в уме "раскручивался" MACRO-11, кто на педепе\ваХ!\СМ работал - подтвердят. Но и он ("первоСи") для своих то времён вот прямо палкой копалкой уже не был. Для этого были ассемблеры. ... Короче - скорее качественный, стандартный шанцевый инструмент :) Кто знает что входило в комплект - тот поймёт, а кто не знает - тот салага и в СА не служил! :-р  :)) Инструмент, которым - таки да! можно! и Чёрное-пречёрное море выкопать ;)  Но зачем!?!?!? 8-о Си __хорош__ для коры ОС, для драйверов, для кодеков, для коры крипты, для лютого байтодроча и бутстрапа диковинного железа, и ___вот_это_вот_всё___ (С)... Для всего остального - есть всё остальное!(С) :) Тут чтобы не начинать флейм на терабайт траффика - без имен. Каждый пользует что ему зашло в этот отрезок времени. Есть _всё_ и на _любой_ вкус, разной степени упоротости и качества, на любой вкус и бюджет. PS: С Наступающим Новым Годом РФ! :-)
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (-), 31-Дек-25, 22:52
	> Перегибаешь ... впрочем это от незнания ;) Или от знания и вьетнамских флешбеков после исправления кода после "настоящих сишников" 😉 > Да - "первоСи"(С) - был конечно элементарным по сравнению с тем что он сейчас, Неужели туда добавили type String? 🙀 > Но и он ("первоСи") для своих то времён вот прямо палкой копалкой уже не был. Для этого были ассемблеры. Ассемблер это когда ты роешь руками) > ... Короче - скорее качественный, стандартный шанцевый инструмент :) Хаха, ну с "качественным" ты загнул. > Но зачем!?!?!? 8-о Логично. Это как хвалить перо и чернильницу. Да чтобы повы###ться подойдет, для реальной работы - уже устарело. Но да, как и уаз, можно выдрать перо из почти любой курицы, а что-то красящее человек выдает в больших количествах. > Си __хорош__ для коры ОС, для драйверов, для кодеков, для коры крипты, > для лютого байтодроча и бутстрапа диковинного железа, и ___вот_это_вот_всё___ (С)... В итоге "кора ОС" дырявая, драйвера дырявые, криптобиблиотеки ... тоже внезапно дырявые. > Каждый пользует что ему зашло в этот отрезок времени. Так пусть пользуются. Но сколько вскруракеков было, когда начали раст в ядро добавлять? Хотя казалось бы, вы простые пользаки, просто закрыли варежки и не мешайте тем, кто ядро делает. > PS: С Наступающим И тебя тоже)
	Ответить | Правка | Наверх | Cообщить модератору

57. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
Сообщение от Аноним (56), 31-Дек-25, 08:37
Кто в теме, можете подсказать? Ошибка-то тупая. Я точно такую не допустил бы (не троллю). Но при этом потратил бы кучу времени на перепроверку кода в результате рефакторинга, чтоб убедиться, что проблем нет. Почему её допустили эти программисты? 1. Не слишком умные? 2. Не слишком заморачиваются при написании кода? 3. Работодатель не даёт достаточно времени на проверки? Я понимаю, когда причины ошибки разбросаны по разным участкам кода, но здесь же прямо в одном выражении понятно, что что-то не так. Спрашиваю у сишников или причастных, кто в теме. Сам программирую на других технологиях, на C иногда пишу для души.
Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (47), 31-Дек-25, 08:51
	4. Ошибка была нужна, иначе как объяснить исправление только с третьего пинка?
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (47), 31-Дек-25, 08:54
	> Уязвимость была добавлена при неудачной попытке исправить предыдущую проблему 5. Просто устали.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	63. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+1 +/–
	Сообщение от Аноним (-), 31-Дек-25, 11:45
	> Спрашиваю у сишников или причастных, кто в теме Просто сишники не умеют писать код. Даже самые крутые лажают. Ну а сам си компиляет любую хню, которую выдавил погромист.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	68. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (47), 31-Дек-25, 14:19
	> сишники не умеют писать код На чём писали первый компилятор раста? Ведь они с твоих слов не умели...
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (-), 31-Дек-25, 15:03
	> На чём писали первый компилятор раста? На OCaml написали первый, а что? А второй на с++. Невозможно написать нормальный оптимизирующий компилятор на сишечке. Вот и llvm, и gcc перешли на плюсы.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (53), 31-Дек-25, 15:20
	> Невозможно написать нормальный оптимизирующий компилятор на сишечке. До 2008г как-то вот gcc существовал на чистой сишке и был оптимизирующим. Вы просто пересказываете одну и ту же байку из раза в раз про то, что на сишке что-то сделать невозможно. Но вы, я смотрю, скорее всего пишете хеллоувроты на расте, иначе бы почитали о причинах перехода с Си на С++ в gcc. Дело там вообще не в оптимизирующем компиляторе.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	–1 +/–
	Сообщение от Аноним (-), 31-Дек-25, 16:27
	> До 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 год. А теперь с удовольствием послушаем вашу версию произошедшего))
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (53), 31-Дек-25, 16:47
	> Прям из первоисточника - презентация Ian Lance Taylor за 2008 год. > А теперь с удовольствием послушаем вашу версию произошедшего)) Ну дак все так и есть, что спорить то если сам автор инициативы так говорит. Только я не вижу в списке причин - на сишке невозможно написать _нормальный_ оптимизирующий компилятор. Был даже где-то видео-доклад ЕМНИП где из всех этих причин он выделил основные две - конструкторы/деструкторы и STL с его контейнерами. Т.е. люди просто захотели отказаться от своих собственных костылей на Си, в которых они сделали свои list'ы, b-tree и тд. Но это не значит что до начала переписывания GCC не существовал и/или был не оптимизирующим. И уж тем более не значит, что это всё нельзя сделать без C++.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (-), 31-Дек-25, 16:58
	> Только я не вижу в списке причин - на сишке невозможно написать _нормальный_ оптимизирующий компилятор. Потому что ты его просто не напишешь, а завязнешь в нагромождении костылей)) > из всех этих причин он выделил основные две - конструкторы/деструкторы > и STL с его контейнерами. Да! Без RAII и контейнеров очень сложно писать большой проект. А GGC сильно разросся. И любой нормальный язык должен это содержать, а не предлагать разработчику велосипедить костыли заново. > Т.е. люди просто захотели отказаться от своих собственных костылей на Си, У них еще на си была самописная сборка мусора. > Но это не значит что до начала переписывания GCC не существовал > и/или был не оптимизирующим. Существовал. Но был намного проще чем сейчас. И оптимизации были существенно проще. > И уж тем более не значит, что это всё нельзя сделать без C++. А вот это уже нужно доказывать. Пока что все современные открытые оптимизирующие компиляторы на си++, а на сишке остались разные древние поделия.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Аноним (53), 31-Дек-25, 17:28
	> И любой нормальный язык должен это содержать, а не предлагать разработчику велосипедить костыли заново. Сомнительно, но... нет, не окей. Вот в C++ есть ключевое слово new и operator new(), которые аллоцируют память динамически в куче. Причем они не часть стандартной библиотеки, а часть самого языка... его семантики, если так можно сказать. Дак вот нафига оно нужно, если я пишу загрузчик MBR, который запускается напрямую BIOS'ом и где нет никакой ОС и тем более стандартной библиотеки чтоб аллоцировать память динамически чепез malloc()? Зачем там new, если его юзать невозможно? Не логично ли было сделать чтоб new был частью библы, а не частью самого языка? Вот и с этими всеми STL, RAII и тд то же самое, но уже в контексте стандартной библиотеки. Не нужно это всё _именно_ в стандартной библиотеке, тем более в сишной. Авторам gcc, конечно же виднее, как им писать их компилятор, но лично я не считаю что свой сборщик мусора, свои контейнеры, списки, массивы, деревья - это костыли. Потому что это все идет в общем дистрибутиве исходников gcc, а не из внешних библиотек, которые надо было бы устанавливать.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Прохожий (??), 01-Янв-26, 12:32
	>Не логично ли было сделать чтоб new был частью библы, а не частью самого языка? Нет, не логично. Обычная библиотечная функция (malloc) не может сама по себе встроиться в цепочку "выделить память > вызвать нужный конструктор > вернуть корректно типизированный указатель" без участия компилятора и специального синтаксиса.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимость в Net-SNMP, допускающая удалённое выполнение кода"	+/–
	Сообщение от Прохожий (??), 01-Янв-26, 12:36
	>лично я не считаю что свой сборщик мусора, свои контейнеры, списки, массивы, деревья - это костыли Много вы компиляторов написали? Это костыли, потому что часто такие самописные поделия не учитывают какие-то инварианты (ввиду ограниченности опыта пишущих), плохо оптимизированы (неэффективны), их тяжело сопровождать.
	Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема