forum.opennet.ru - "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не полностью" (61)

"Из-за ошибки уязвимость в libnv была устранена во FreeBSD не полностью"

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

"Из-за ошибки уязвимость в libnv была устранена во FreeBSD не полностью"	+/–
Сообщение от opennews (??), 30-Сен-24, 09:01
В выпущенном в начале сентября исправлении уязвимости в библиотеке libnv выявлена логическая ошибка, из-за которой уязвимость не устранялась должным образом и система оставалась подвержена атаке. Библиотека libnv развивается проектом FreeBSD и используется в ядре и в приложениях из базовой системы для обработки списков в формате ключ/значение и для огранизации передачи данных при межпроцессном взаимодействии. Библиотека основана на алгоритме nvlist, применяемом в проекте OpenZFS, но во FreeBSD создана собственная реализация, поэтому уязвимость не затрагивает OpenZFS... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61956
Ответить \| Правка \| Cообщить модератору

Оглавление

Лихо Надо полагать, что большинство связаны с сишкой Очевидно, язык не справля, Аноним (1), 09:01 , 30-Сен-24, (1) –16

Вот это приплёл , Аноним (3), 09:12 , 30-Сен-24, (3) +5

А, что, это не очевидно С чем же ещё Читайте что написано, опять и опять Уяз, Кулёк (?), 18:22 , 30-Сен-24, (81)

А какой справляется , Аноним (4), 09:13 , 30-Сен-24, (4) +1

Turbopascal , Аноним (13), 10:44 , 30-Сен-24, (13) +2

В нём тоже указатели можно , Аноним (42), 12:42 , 30-Сен-24, (42)

А причем тут язык Тут проблемы в квалификации Надо менять подходы Например, для, Аноним (-), 10:54 , 30-Сен-24, (17) –3
А что, задача была в безопасность Вы, когда пишете код, сильно про безопасность, Аноним (23), 11:29 , 30-Сен-24, (23) –2

думать о безопасности, задача безопасников , Аноним (30), 11:41 , 30-Сен-24, (30)
У кого-то ведь в ответственности не только личные ПК с игрульками Приходится ду, Аноним (54), 14:43 , 30-Сен-24, (54) +1

Да У кого-то где-то, но не у вас Вы-то что так бурно реагируете на новости о б, Аноним (78), 18:20 , 30-Сен-24, (78)

Задача всегда в безопасность Была, есть и будет , YetAnotherOnanym (ok), 15:47 , 30-Сен-24, (63)

Ваши вычислительные мощности как-то пострадали от дыр , Аноним (78), 18:22 , 30-Сен-24, (80)

Что за обществу вы задаёте вопрос Может быть вы задаёте его так называемому со, Активист (?), 16:56 , 30-Сен-24, (70)

Надо полагать, что большинство связаны с комитерами, коих 2000 бывает Всех не , Аноним (42), 12:34 , 30-Сен-24, (38)

Другой язык программирования никак не сможет проверить этих 2000 а три буквы вст, Аноним (52), 14:26 , 30-Сен-24, (52)
Так сам финский студент на три буквы работает , Аноним (54), 14:44 , 30-Сен-24, (55)

Да, да Хоть Гугль то почитайте , Активист (?), 17:02 , 30-Сен-24, (71)

Ha-ha Classic , Аноним (-), 09:26 , 30-Сен-24, (6) +2
Мда Знатное peшeто это ваше ядро Вот что бывает, когда десятилетиями омнокодя, Аноним (10), 09:52 , 30-Сен-24, (10)

Надо было Hurd развивать, а не вот это вот всё , Аноним (11), 10:21 , 30-Сен-24, (11)

Но к большому сожалению академические мужы оказались более тщепетмльны и медлите, Аноним (54), 14:47 , 30-Сен-24, (56) +1

на академических мужей подали в суд и затянулись эти суды на годы Поэтому индуст, Аноним (-), 15:55 , 30-Сен-24, (64)
А не то вышло бы как паровоз в 21 веке Я понимаю, что вам луддитам того и надо, Активист (?), 17:05 , 30-Сен-24, (72)

Если бы такие, как вы, принципиально отказались бы от использования небезопасных, Аноним (62), 15:44 , 30-Сен-24, (62)

Неужели целочисленное переполнение нельзя отследить на этапе компиляции и какой-, Аноним (12), 10:24 , 30-Сен-24, (12)

Некоторую часть можно компиляторами, ещё часть статическими анализаторами можно , topin89 (ok), 10:46 , 30-Сен-24, (14) –1

Еще один умник Причем здесь язык к переполнению Лишь бы на вентилятор набросит, Денис Попов (?), 11:24 , 30-Сен-24, (20)

Очевидно, речь про работу с создаваемыми на ходу объектами Тогда чтобы найти, н, Аноним (24), 11:31 , 30-Сен-24, (24)
А при том Берем какой-то безопасный язык, например ADA-Spark и смотрим их доку d, Аноним (-), 11:35 , 30-Сен-24, (28)

Только ты забыл упомянуть что ада тормозит , Аноним (52), 12:44 , 30-Сен-24, (44)

Так тебе тормоза или рут всем и пусть никто не уйдет обиженным Нафига вообще , Аноним (-), 14:01 , 30-Сен-24, (49)

Давай тогда все на питоне будем писать тогда Раз не торопимся Зачем ада , Аноним (52), 16:27 , 30-Сен-24, (67)

Используй тогда gmplib никакого переполнения не будетЕсли где-то gmplib и что-то, Mister (??), 19:34 , 30-Сен-24, (97)

Разработчики на Rust сейчас ты не поверишь , Аноним (16), 10:52 , 30-Сен-24, (16)

А что в расте Там варн Или не даёт скомпилировать, пока явно не защитишься от , Аноним (12), 11:22 , 30-Сен-24, (19)
А что на раст Там каждое сложение проверяется на переполнение на этапе конь-эпи, Аноним (21), 11:27 , 30-Сен-24, (21)
Не поверю Человек должен решать, т к иногда именно отсутствия обработки перепо, Денис Попов (?), 11:29 , 30-Сен-24, (22)

За храстовиков все должен решать храст , Аноним (52), 11:55 , 30-Сен-24, (34) +1
100 Поэтому в языки добавили saturating_add, wrapping_add, overflowing_add, std , Аноним (-), 12:27 , 30-Сен-24, (37) +1

Языки не нужны код должны писать нейросети , Аноним (52), 13:42 , 30-Сен-24, (48)

Ваша профессия тем более, её должны выполнять автоматы роботы , Аноним (54), 14:50 , 30-Сен-24, (58)

Нейросети должны писать код для роботов так наступит сингу Апокалипсис , Аноним (52), 14:59 , 30-Сен-24, (60) +2

Так основная проблема не с самим переполнением, а с тем, что его результат напр , Аноним (-), 11:32 , 30-Сен-24, (25)
Даже раст в продовой сборке не спасает от переполнения , Аноним (52), 11:34 , 30-Сен-24, (27) +2

Что значит не спасет Переполнение это обычное поведение Проблема не в перепо, Аноним (-), 11:39 , 30-Сен-24, (29) –1

А от записи за пределы буфера спасёт , Аноним (12), 11:49 , 30-Сен-24, (32) +1

Да, вот от этого спасет Проверки на выход за границы есть в релизе по умолчанию , Аноним (-), 12:19 , 30-Сен-24, (35)

Получается действительно хороший инструмент, что бы хейтеры не говорили, Аноним (12), 12:23 , 30-Сен-24, (36) –2

Нет плохой , Аноним (52), 19:28 , 30-Сен-24, (95)

Почему , Аноним (12), 19:31 , 30-Сен-24, (96)

На Си тоже самое так что раст не надобен , Аноним (52), 11:54 , 30-Сен-24, (33)

Спасает, если использовать функции вместо оператора , Аноним (65), 16:13 , 30-Сен-24, (65)

Есть два типа программистов на Си первые не проверяют границы буферов, вторые п, Аноним (68), 16:38 , 30-Сен-24, (68)

Таки приходите когда на вашем чуднОм языке будет написано хотя 0,001 от того чт, Ivan_83 (ok), 17:41 , 30-Сен-24, (74)

Над аргументом сперва добейся в интернете ещё двадцать лет назад смеялись, Аноним (12), 18:12 , 30-Сен-24, (77) –1
Это на каком же именно И при чём тут другие языки к Си Факт остаётся фактом с, Аноним (68), 18:21 , 30-Сен-24, (79)

Факт остаётся фактом никто другой ниасилил массовое, популярное, производительн, _ (??), 18:53 , 30-Сен-24, (89)

Ядро, мазут, локти 8212 это всё понятно, к объективной реальности несовершенс, Аноним (68), 19:07 , 30-Сен-24, (91)

Все исправляется по мире нахождения Используй друг языки кто тебе мешает , Аноним (52), 19:28 , 30-Сен-24, (94)

Мне никто не мешает Проблема не в моих возможностях, а в плачевном состоянии ги, Аноним (68), 20:06 , 30-Сен-24, (98)

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

1. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." –16 +/–

Сообщение от Аноним (1), 30-Сен-24, 09:01

>было исправлено ещё 345
Лихо. Надо полагать, что большинство связаны с сишкой. Очевидно, язык не справляется со своими задачами.

Ответить | Правка | Наверх | Cообщить модератору

3. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +5 +/–

Сообщение от Аноним (3), 30-Сен-24, 09:12

Вот это приплёл...

Ответить | Правка | Наверх | Cообщить модератору

81. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Кулёк (?), 30-Сен-24, 18:22

А, что, это не очевидно? С чем же ещё? Читайте что написано, опять и опять: "Уязвимости вызваны обращением к уже освобождённой области памяти". В Rust таких проблем нет. И не надо опять вот тут что там всё unsafe посыпано. Иногда просто нет возможности гарантировать безопасность, но есть очень большая разница когда ты сознательно делаешь opt-in и ограничиваешь область такого кода и тем когда у тебя весь код потенциально одна большая проблема с безопасностью как в случае с С/С++.
Всё уже выяснили, Google вон делал исследование по поводу безопасности, там всё ясно и понятно: хочешь меньше проблем - не пиши код на Си, только фикси его, всё новое - только на Rust.
Си не уходит исключительно потому что много людей которые его уже знают и много кода написано, но это всё конечно же изменится со временем. А потом и Rust заменится чем-нибудь более продвинутым. Это называется "прогресс". 20 лет назад такие же сидели и ныли что нафиг нам питон вместо фортрана, ну и где он?

Ответить | Правка | Наверх | Cообщить модератору

4. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +1 +/–

Сообщение от Аноним (4), 30-Сен-24, 09:13

А какой справляется?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

13. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +2 +/–

Сообщение от Аноним (13), 30-Сен-24, 10:44

Turbopascal)

Ответить | Правка | Наверх | Cообщить модератору

42. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Аноним (42), 30-Сен-24, 12:42

В нём тоже указатели можно.

Ответить | Правка | Наверх | Cообщить модератору

17. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." –3 +/–

Сообщение от Аноним (-), 30-Сен-24, 10:54

> Очевидно, язык не справляется со своими задачами.
А причем тут язык?
Тут проблемы в квалификации! Надо менять подходы.
Например, для PR в ядро, обязать чтобы код проходил стат. анализаторы, добавить фаззинг, публично осуждать бракоделов (можно взять Линуса и дать ему затачу показывать им пальцы)

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

23. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." –2 +/–

Сообщение от Аноним (23), 30-Сен-24, 11:29

А что, задача была в безопасность? Вы, когда пишете код, сильно про безопасность думаете? Что ж вы так за безопасность переживаете? Есть примеры, когда лично ваш ПК пострадал из-за дыр в безопасности?
Пс. Не к вам лично вопрос, а к обществу, которое бурно реагирует на такие новости.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

30. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Аноним (30), 30-Сен-24, 11:41

> Вы, когда пишете код, сильно про безопасность думаете?
думать о безопасности, задача безопасников!

Ответить | Правка | Наверх | Cообщить модератору

54. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +1 +/–

Сообщение от Аноним (54), 30-Сен-24, 14:43

У кого-то ведь в ответственности не только личные ПК с игрульками. Приходится думать.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

78. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Аноним (78), 30-Сен-24, 18:20

Да. У кого-то где-то, но не у вас. Вы-то что так бурно реагируете на новости о безопасности?

Ответить | Правка | Наверх | Cообщить модератору

63. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от YetAnotherOnanym (ok), 30-Сен-24, 15:47

Задача всегда в безопасность. Была, есть и будет.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

80. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Аноним (78), 30-Сен-24, 18:22

Ваши вычислительные мощности как-то пострадали от дыр?

Ответить | Правка | Наверх | Cообщить модератору

70. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Активист (?), 30-Сен-24, 16:56

Что за обществу вы задаёте вопрос? Может быть вы задаёте его так называемому "сообществу"? Тогда я уверю вас, что стакан недостаточно полон, чтобы из него что-то выплёскивалось при бурлении.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

38. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Аноним (42), 30-Сен-24, 12:34

Надо полагать, что большинство связаны с комитерами, коих >2000 бывает. Всех не проверишь. Наверняка, есть и от организаций с трёхбуквенными названиями.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

52. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Аноним (52), 30-Сен-24, 14:26

Другой язык программирования никак не сможет проверить этих 2000 а три буквы вставят что надо на любом языке. Даже на языке жестов.

Ответить | Правка | Наверх | Cообщить модератору

55. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Аноним (54), 30-Сен-24, 14:44

Так сам финский студент на три буквы работает.

Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

71. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..." +/–

Сообщение от Активист (?), 30-Сен-24, 17:02

Да, да. Хоть Гугль то почитайте.

Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +2 +/–

Сообщение от Аноним (-), 30-Сен-24, 09:26

> обращением к уже освобождённой области памяти в функциях
> и позволяют добиться выполнения кода с правами root
Ha-ha.
Classic.

Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (10), 30-Сен-24, 09:52

> в июньском обновлении пакета с ядром 5.10 в Debian помимо CVE-2024-26808
> было исправлено ещё 345 (!) потенциальных уязвимостей
Мда... Знатное peшeто это ваше ядро.
Вот что бывает, когда десятилетиями омнокодят и кладут болтяру на безопасность.
Думаю что в ядре ситуация еще хуже чем в иксах))

Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (11), 30-Сен-24, 10:21

Надо было Hurd развивать, а не вот это вот всё.

Ответить | Правка | Наверх | Cообщить модератору

56. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +1 +/–

Сообщение от Аноним (54), 30-Сен-24, 14:47

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

Ответить | Правка | Наверх | Cообщить модератору

64. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (-), 30-Сен-24, 15:55

> к большому сожалению
на академических мужей подали в суд и затянулись эти суды на годы.
Поэтому индустрия легкого поведения побежала за скорострелом.

Ответить | Правка | Наверх | Cообщить модератору

72. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Активист (?), 30-Сен-24, 17:05

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

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

62. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (62), 30-Сен-24, 15:44

> Надо было Hurd развивать, а не вот это вот всё.
Если бы такие, как вы, принципиально отказались бы от использования небезопасных систем типа linux, и принципиально использовали бы только системы на базе хурд, то, возможно, Линус бы и задумался. Но вы ж бежите на небезопасное, делаемое тяп-ляп, которое скомпилировалось - и хорошо. Потому корпорации и не развивают хурд и подобные, а вкладываются в линукс - это проще, думать шибко не надо, и вместо программистов можно индусов нанять.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

12. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (12), 30-Сен-24, 10:24

Неужели целочисленное переполнение нельзя отследить на этапе компиляции и какой-нибудь варн показать? Вроде бы проблеме сто лет в обед, а всё равно раз за разом повторяется

Ответить | Правка | Наверх | Cообщить модератору

14. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." –1 +/–

Сообщение от topin89 (ok), 30-Сен-24, 10:46

Некоторую часть можно компиляторами, ещё часть статическими анализаторами можно. Большую часть только при живом запуске на тестах. Что поделаешь, программирование на C и C++ -- это хотьба на канате над пропастью. Чуть зазевался -- и лови CVE.

Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Денис Попов (?), 30-Сен-24, 11:24

Еще один умник. Причем здесь язык к переполнению? Лишь бы на вентилятор набросить...

Ответить | Правка | Наверх | Cообщить модератору

24. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (24), 30-Сен-24, 11:31

Очевидно, речь про работу с создаваемыми на ходу объектами. Тогда чтобы найти, нужно разобраться как работает алгоритм. ИИ может что-то и мог бы, но это пока дорого и не совсем доступно.
И когда работа с памятью идёт вручную, то все недостатки ручной работы - ошибки человека. Автоматизация убирает такое. В каких-то языках автоматика присутствует. Те языки часто хейтят.

Ответить | Правка | Наверх | Cообщить модератору

28. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (-), 30-Сен-24, 11:35

А при том.
Берем какой-то безопасный язык, например ADA-Spark и смотрим их доку.
docs.adacore.com/spark2014-docs/html/ug/en/source/overflow_modes.html
Ого сколько тут всего интересного О_О
Но самое главное - однозначного!
Тут нет сишного овна типа "мы тут хз как сложить два числа, пусть компилятор думает, он же умный" с последущим UB.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

44. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (52), 30-Сен-24, 12:44

Только ты забыл упомянуть что ада тормозит.

Ответить | Правка | Наверх | Cообщить модератору

49. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (-), 30-Сен-24, 14:01

> Только ты забыл упомянуть что ада тормозит.
Так тебе тормоза или "рут всем и пусть никто не уйдет обиженным" ?
Нафига вообще какие-то пароли, попытки изоляции и прочее, если нам главное "шобы побыстрее".
Если тормозит - просто возьмо процессор помощнее, как говорил Тодд.

Ответить | Правка | Наверх | Cообщить модератору

67. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (52), 30-Сен-24, 16:27

Давай тогда все на питоне будем писать тогда. Раз не торопимся. Зачем ада.

Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Mister (??), 30-Сен-24, 19:34

Используй тогда gmplib никакого переполнения не будет
Если где-то gmplib и что-то подобное встроено по умолчанию, то это не значит, что так надо везде
Ещё можешь флаг процессора на переполнение проверять после каждой операции

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

16. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (16), 30-Сен-24, 10:52

> на этапе компиляции и какой-нибудь варн показать
Разработчики на Rust сейчас: ты не поверишь!

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

19. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (12), 30-Сен-24, 11:22

А что в расте? Там варн? Или не даёт скомпилировать, пока явно не защитишься от переполнения? (я не знаком с растом)

Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (21), 30-Сен-24, 11:27

А что на раст? Там каждое сложение проверяется на переполнение на этапе конь-эпиляции?

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

22. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Денис Попов (?), 30-Сен-24, 11:29

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

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

34. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +1 +/–

Сообщение от Аноним (52), 30-Сен-24, 11:55

За храстовиков все должен решать храст.

Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +1 +/–

Сообщение от Аноним (-), 30-Сен-24, 12:27

100%
Поэтому в языки добавили saturating_add, wrapping_add, overflowing_add, std::add_sat и другие аналогичные операции, которые будут гарантировано давать поведение, нужное разработчику в данном месте.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

48. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (52), 30-Сен-24, 13:42

Языки не нужны код должны писать нейросети.

Ответить | Правка | Наверх | Cообщить модератору

58. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (54), 30-Сен-24, 14:50

Ваша профессия тем более, её должны выполнять автоматы/роботы.

Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +2 +/–

Сообщение от Аноним (52), 30-Сен-24, 14:59

Нейросети должны писать код для роботов так наступит сингу... Апокалипсис.

Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (-), 30-Сен-24, 11:32

> Неужели целочисленное переполнение нельзя отследить на этапе компиляции и какой-нибудь варн показать?
Так основная проблема не с самим переполнением, а с тем, что его результат напр. используется как индекс.
И оно пишет непонятно куда, портит память, дарит рут.
Плюс переполнение signed вообще UB, т.е. одно и тоже переполнение может на разных компиляторах, с разными флагами давать разные результат.
В "других языках"(с) поведение для signed переполнения зафиксировано.
А от попытки писать хз куда защищают другие механизмы.
Плюс можно включить проверку в релизе используя опцию overflow-checks (в дебаге она и так включена, но можно выключить при желании)

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

27. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +2 +/–

Сообщение от Аноним (52), 30-Сен-24, 11:34

Даже раст в продовой сборке не спасает от переполнения.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

29. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." –1 +/–

Сообщение от Аноним (-), 30-Сен-24, 11:39

Что значит "не спасет"?. Переполнение это обычное поведение.
Проблема не в переполнении, а в том что происходит после - т.е порча памяти и рут.
Пусть она выдает неверный результат - найдем на тестах (хаха, если они у нас есть) или фаззинге.
Пусть программа падает - получим логи, исправим ошибку.
Но по тихому сломаться и сделать CVE - от такого точно не должно быть.

Ответить | Правка | Наверх | Cообщить модератору

32. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +1 +/–

Сообщение от Аноним (12), 30-Сен-24, 11:49

А от записи за пределы буфера спасёт?

Ответить | Правка | Наверх | Cообщить модератору

35. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (-), 30-Сен-24, 12:19

> А от записи за пределы буфера спасёт?
Да, вот от этого спасет.
Проверки на выход за границы есть в релизе по умолчанию.

Ответить | Правка | Наверх | Cообщить модератору

36. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." –2 +/–

Сообщение от Аноним (12), 30-Сен-24, 12:23

Получается действительно хороший инструмент, что бы хейтеры не говорили

Ответить | Правка | Наверх | Cообщить модератору

95. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (52), 30-Сен-24, 19:28

Нет плохой.

Ответить | Правка | Наверх | Cообщить модератору

96. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (12), 30-Сен-24, 19:31

Почему?

Ответить | Правка | Наверх | Cообщить модератору

33. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (52), 30-Сен-24, 11:54

На Си тоже самое так что раст не надобен.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

65. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (65), 30-Сен-24, 16:13

Спасает, если использовать функции вместо оператора +

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

68. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (68), 30-Сен-24, 16:38

> вызвана недостаточной проверкой границ буфера
Есть два типа программистов на Си: первые не проверяют границы буферов, вторые проверяют, но недостаточно. Пожалуй, это всё, что нужно знать о культуре разработки на этом языке.

Ответить | Правка | Наверх | Cообщить модератору

74. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Ivan_83 (ok), 30-Сен-24, 17:41

Таки приходите когда на вашем чуднОм языке будет написано хотя 0,001% от того что написано на С, и это будут не вариации хэлло ворлда и прочих прог на 10 строк а нечто на 50к+ строк.

Ответить | Правка | Наверх | Cообщить модератору

77. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." –1 +/–

Сообщение от Аноним (12), 30-Сен-24, 18:12

Над аргументом "сперва добейся" в интернете ещё двадцать лет назад смеялись

Ответить | Правка | Наверх | Cообщить модератору

79. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (68), 30-Сен-24, 18:21

> на вашем чуднОм языке
Это на каком же именно? И при чём тут другие языки к Си? Факт остаётся фактом: сишные кодеры в целом, как культурное явление, не смогли за пятьдесят лет решить типичные проблемы с менеджментом памяти.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

89. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от _ (??), 30-Сен-24, 18:53

Факт остаётся фактом: никто другой ниасилил массовое, популярное, производительное и (sic!!!) достаточно безопасное (да-да!!) ядро.
Это ж вам не чистые функции в вакууме, это ж по локоть в мазуте в железных потрохах ковыряться  :(
Поэтому возьмите свои замечательные и классные языки, без всяких там подколов - замечательные и классные!, и идите ка в свой юзерланд.
Как добрый старый дяденька вам советую :)

Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (68), 30-Сен-24, 19:07

Ядро, мазут, локти — это всё понятно, к объективной реальности несовершенства оборудования вопросов нет. Почему память пятьдесят лет течёт и перезаписывается из-за буквально одних и тех же ошибок, и когда это будет исправлено на уровне культуры разработки (про тулинг и стандарт даже не спрашиваю)?

Ответить | Правка | Наверх | Cообщить модератору

94. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (52), 30-Сен-24, 19:28

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

Ответить | Правка | Наверх | Cообщить модератору

98. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..." +/–

Сообщение от Аноним (68), 30-Сен-24, 20:06

Мне никто не мешает. Проблема не в моих возможностях, а в плачевном состоянии гигиены в сообществе кодеров на Си.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–16 +/–
Сообщение от Аноним (1), 30-Сен-24, 09:01
>было исправлено ещё 345 Лихо. Надо полагать, что большинство связаны с сишкой. Очевидно, язык не справляется со своими задачами.
Ответить \| Правка \| Наверх \| Cообщить модератору


	3. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+5 +/–
	Сообщение от Аноним (3), 30-Сен-24, 09:12
	Вот это приплёл...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	81. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Кулёк (?), 30-Сен-24, 18:22
	А, что, это не очевидно? С чем же ещё? Читайте что написано, опять и опять: "Уязвимости вызваны обращением к уже освобождённой области памяти". В Rust таких проблем нет. И не надо опять вот тут что там всё unsafe посыпано. Иногда просто нет возможности гарантировать безопасность, но есть очень большая разница когда ты сознательно делаешь opt-in и ограничиваешь область такого кода и тем когда у тебя весь код потенциально одна большая проблема с безопасностью как в случае с С/С++. Всё уже выяснили, Google вон делал исследование по поводу безопасности, там всё ясно и понятно: хочешь меньше проблем - не пиши код на Си, только фикси его, всё новое - только на Rust. Си не уходит исключительно потому что много людей которые его уже знают и много кода написано, но это всё конечно же изменится со временем. А потом и Rust заменится чем-нибудь более продвинутым. Это называется "прогресс". 20 лет назад такие же сидели и ныли что нафиг нам питон вместо фортрана, ну и где он?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+1 +/–
	Сообщение от Аноним (4), 30-Сен-24, 09:13
	А какой справляется?
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	13. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+2 +/–
	Сообщение от Аноним (13), 30-Сен-24, 10:44
	Turbopascal)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	42. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (42), 30-Сен-24, 12:42
	В нём тоже указатели можно.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–3 +/–
	Сообщение от Аноним (-), 30-Сен-24, 10:54
	> Очевидно, язык не справляется со своими задачами. А причем тут язык? Тут проблемы в квалификации! Надо менять подходы. Например, для PR в ядро, обязать чтобы код проходил стат. анализаторы, добавить фаззинг, публично осуждать бракоделов (можно взять Линуса и дать ему затачу показывать им пальцы)
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	23. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	–2 +/–
	Сообщение от Аноним (23), 30-Сен-24, 11:29
	А что, задача была в безопасность? Вы, когда пишете код, сильно про безопасность думаете? Что ж вы так за безопасность переживаете? Есть примеры, когда лично ваш ПК пострадал из-за дыр в безопасности? Пс. Не к вам лично вопрос, а к обществу, которое бурно реагирует на такие новости.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	30. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (30), 30-Сен-24, 11:41
	> Вы, когда пишете код, сильно про безопасность думаете? думать о безопасности, задача безопасников!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+1 +/–
	Сообщение от Аноним (54), 30-Сен-24, 14:43
	У кого-то ведь в ответственности не только личные ПК с игрульками. Приходится думать.
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	78. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (78), 30-Сен-24, 18:20
	Да. У кого-то где-то, но не у вас. Вы-то что так бурно реагируете на новости о безопасности?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	63. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от YetAnotherOnanym (ok), 30-Сен-24, 15:47
	Задача всегда в безопасность. Была, есть и будет.
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	80. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (78), 30-Сен-24, 18:22
	Ваши вычислительные мощности как-то пострадали от дыр?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Активист (?), 30-Сен-24, 16:56
	Что за обществу вы задаёте вопрос? Может быть вы задаёте его так называемому "сообществу"? Тогда я уверю вас, что стакан недостаточно полон, чтобы из него что-то выплёскивалось при бурлении.
	Ответить \| Правка \| К родителю #23 \| Наверх \| Cообщить модератору


	38. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (42), 30-Сен-24, 12:34
	Надо полагать, что большинство связаны с комитерами, коих >2000 бывает. Всех не проверишь. Наверняка, есть и от организаций с трёхбуквенными названиями.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	52. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (52), 30-Сен-24, 14:26
	Другой язык программирования никак не сможет проверить этих 2000 а три буквы вставят что надо на любом языке. Даже на языке жестов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Аноним (54), 30-Сен-24, 14:44
	Так сам финский студент на три буквы работает.
	Ответить \| Правка \| К родителю #38 \| Наверх \| Cообщить модератору


	71. "Из-за ошибки уязвимость в libnv была устранена во FreeBSD не..."	+/–
	Сообщение от Активист (?), 30-Сен-24, 17:02
	Да, да. Хоть Гугль то почитайте.
	Ответить \| Правка \| Наверх \| Cообщить модератору

6. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+2 +/–
Сообщение от Аноним (-), 30-Сен-24, 09:26
> обращением к уже освобождённой области памяти в функциях > и позволяют добиться выполнения кода с правами root Ha-ha. Classic.
Ответить \| Правка \| Наверх \| Cообщить модератору

10. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
Сообщение от Аноним (10), 30-Сен-24, 09:52
> в июньском обновлении пакета с ядром 5.10 в Debian помимо CVE-2024-26808 > было исправлено ещё 345 (!) потенциальных уязвимостей Мда... Знатное peшeто это ваше ядро. Вот что бывает, когда десятилетиями омнокодят и кладут болтяру на безопасность. Думаю что в ядре ситуация еще хуже чем в иксах))
Ответить \| Правка \| Наверх \| Cообщить модератору


	11. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (11), 30-Сен-24, 10:21
	Надо было Hurd развивать, а не вот это вот всё.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+1 +/–
	Сообщение от Аноним (54), 30-Сен-24, 14:47
	Но к большому сожалению академические мужы оказались более тщепетмльны и медлительны, чем финский скорострел. Вышло как вышло.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	64. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 15:55
	> к большому сожалению на академических мужей подали в суд и затянулись эти суды на годы. Поэтому индустрия легкого поведения побежала за скорострелом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	72. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Активист (?), 30-Сен-24, 17:05
	А не то вышло бы как паровоз в 21 веке. (Я понимаю, что вам луддитам того и надо). Так фряха же есть более-менее окаменелая. Но почему-то вы туда не спешите.
	Ответить \| Правка \| К родителю #56 \| Наверх \| Cообщить модератору


	62. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (62), 30-Сен-24, 15:44
	> Надо было Hurd развивать, а не вот это вот всё. Если бы такие, как вы, принципиально отказались бы от использования небезопасных систем типа linux, и принципиально использовали бы только системы на базе хурд, то, возможно, Линус бы и задумался. Но вы ж бежите на небезопасное, делаемое тяп-ляп, которое скомпилировалось - и хорошо. Потому корпорации и не развивают хурд и подобные, а вкладываются в линукс - это проще, думать шибко не надо, и вместо программистов можно индусов нанять.
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору

12. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
Сообщение от Аноним (12), 30-Сен-24, 10:24
Неужели целочисленное переполнение нельзя отследить на этапе компиляции и какой-нибудь варн показать? Вроде бы проблеме сто лет в обед, а всё равно раз за разом повторяется
Ответить \| Правка \| Наверх \| Cообщить модератору


	14. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	–1 +/–
	Сообщение от topin89 (ok), 30-Сен-24, 10:46
	Некоторую часть можно компиляторами, ещё часть статическими анализаторами можно. Большую часть только при живом запуске на тестах. Что поделаешь, программирование на C и C++ -- это хотьба на канате над пропастью. Чуть зазевался -- и лови CVE.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Денис Попов (?), 30-Сен-24, 11:24
	Еще один умник. Причем здесь язык к переполнению? Лишь бы на вентилятор набросить...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	24. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (24), 30-Сен-24, 11:31
	Очевидно, речь про работу с создаваемыми на ходу объектами. Тогда чтобы найти, нужно разобраться как работает алгоритм. ИИ может что-то и мог бы, но это пока дорого и не совсем доступно. И когда работа с памятью идёт вручную, то все недостатки ручной работы - ошибки человека. Автоматизация убирает такое. В каких-то языках автоматика присутствует. Те языки часто хейтят.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	28. "Уязвимость в libnv во FreeBSD и уязвимости в Netfilter в Lin..."	+/–
	Сообщение от Аноним (-), 30-Сен-24, 11:35
	А при том. Берем какой-то безопасный язык, например ADA-Spark и смотрим их доку. docs.adacore.com/spark2014-docs/html/ug/en/source/overflow_modes.html Ого сколько тут всего интересного О_О Но самое главное - однозначного! Тут нет сишного овна типа "мы тут хз как сложить два числа, пусть компилятор думает, он же умный" с последущим UB.
	Ответить \| Правка \| К родителю #20 \| Наверх \| Cообщить модератору