The OpenNET Project / Index page

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



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

Оглавление

Уязвимость в утилите GNU split, приводящая к переполнению буфера, opennews (??), 24-Янв-24, (0) [смотреть все]

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


3. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от Аноним (3), 24-Янв-24, 10:37 
Нет, ну а что хотят уважаемые эксперты по Си? Сишка - сложный системный язычок, чтобы на нём писать, погроммист должен 150 раз обдумать поведение каждой строчки на выход за пределы, переполнение, нулевые указатели-сегфолт, деление на ноль и т.д. и т.п. На написание полностью безопасной утилиты на Си нужно много лет работы лучших инженеров по Си, вот так то...
Ответить | Правка | Наверх | Cообщить модератору

8. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –2 +/
Сообщение от Аноним (8), 24-Янв-24, 10:49 
Другое дело раст: мозги в принципе не включают, считая что safe магия их спасет от всех проблем, а она почему-то не работает, да ещё новые проблемы добавляет. Так ещё и гораздо медленнее. Но в каждой новости конечно хруст надо приплести, который с 2014 года использовался только во всякой ерунде.
Ответить | Правка | Наверх | Cообщить модератору

11. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/
Сообщение от Аноним (3), 24-Янв-24, 10:53 
Причём тута раст? Я пишу про сишку! Тебе раст просто мерещится! Кроме раста есть плюсы, хоть громоздкие, но там есть сморт пойнторс и RAII, а сишка - это же вообще технология без всякой защиты. Язычок из 80-х годов.
Ответить | Правка | Наверх | Cообщить модератору

20. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +2 +/
Сообщение от Аноним (20), 24-Янв-24, 11:38 
> а сишка - это же вообще технология без всякой защиты

то что надо для написания ядер ОС и драйвер. А всякие умные указатели и прочие RAII - это всё для прикладухи, а не для системщины.

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

22. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +2 +/
Сообщение от Аноним (22), 24-Янв-24, 11:41 
> то что надо для написания ядер ОС и драйвер.

Да, именно то что нужно!
Чтобы дырень в твоем драйвере, написанном лучшими погромистами из имеющихся, рутанула тебе всю ОСь))

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

25. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/
Сообщение от Аноним (20), 24-Янв-24, 12:01 
ОЙ, да не завидуй ты так. Ты ни на каком языке никакого драйвера не напишет, даже на самом безопасном.
Ответить | Правка | Наверх | Cообщить модератору

53. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –2 +/
Сообщение от Аноним (53), 24-Янв-24, 13:55 
Лучше тот, кто не пишет драйверов, чем тот, кто пишет их на сишке.
Первый хотя бы не делает хуже.
Ответить | Правка | Наверх | Cообщить модератору

97. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +6 +/
Сообщение от Аноним (20), 24-Янв-24, 17:02 
Ты получается круче всех инженеров в IBM/RedHat. Я горжусь, что живу в одно время с такими людьми и имею возможность с ними на форуме общаться.
Ответить | Правка | Наверх | Cообщить модератору

118. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от Аноним (106), 24-Янв-24, 18:01 
Он прав. Ядра ОС это пожалуй единственная ниша для сишки. Драйверы - нет.
Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

30. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от adolfus (ok), 24-Янв-24, 12:35 
Если внимательно читать IEEE Std 1003.1 aka POSIX и разного рода rationale про функции системного интерфейса, то там обращается особое внимание на то, что никаких проверок на входе в функции системного интерфейса (в числе которых, кстати, и содержимое libc) чтобы предотвратить ситуации, которые в стандарте языка си описаны как "неопределенное поведение" и "ошибки", не производится -- это ответственность программиста.
Так что если не согласны с такого рода положением, к вашим услугам разного рода фреймворки, написанные, кстати, на си, поверх той же самой libc.
А не изучив стандарты на си, на c++ и posix нефиг рассусоливать про какие-то "безопасные" языки. Под этими "безопасными" языками (за редким исключением экзотических архитектур)  лежит тот-же "небезопасный" си и "небезопасная" libc.
НЯП, настоящих языков программирования, компиляторы которых написаны на них же или на ассемблере, меньше десятка -- С, C++, FORTRАN, COBOL, несколько виртовских языков и все. Остальное -- обертки над ними, но большей частью над С и С++. Кстати, есть такой стиль программирования -- backend+frontend. Вот, например, питон -- он четко следует именно такой парадигме -- внизу в качестве бакенда c+libc, сверху он -- фронтенд.

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

137. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/
Сообщение от stalinus (?), 24-Янв-24, 19:32 
Всё верно, но зря ты так подробно расписал. Анонимы opennet читают первые десять слов, а дальше у них происходит переполнение буфера со стиранием уже прочитанного.
Ответить | Правка | Наверх | Cообщить модератору

150. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +1 +/
Сообщение от Аноним (-), 24-Янв-24, 23:20 
> "дальше у них происходит переполнение буфера со стиранием уже прочитанного"

Они что тоже на СИ написаны?
Вот это откровение!
Но тогда понятно почему некоторые настолько дырявые)

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

170. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от berium (?), 25-Янв-24, 05:30 
Переполнение буфера реализуется в коде на любом языке программирования, даже Rust от этого не спасёт.
Ответить | Правка | Наверх | Cообщить модератору

158. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от Аноним (158), 24-Янв-24, 23:51 
Тебе про Фому, а ты про сисколы. Да еще и человека соблазнил тебе чаю подлить.
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

28. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +5 +/
Сообщение от Аноним (-), 24-Янв-24, 12:16 
А сишники забавные ребята. Каждый раз когда ты начинаешь их мордочкой тыкать в их... эээ... код, они начинают верещать про раст, про его проблемы, то что он не серебрянная пуля и тд.
Мы тут не раст обсуждаем, да и кроме него есть еще другие языки.
Скажите уже что-то дельно в оправдание дыряшки. А пока что мозги не включают сишники.

PS. хруст первым приплел ты))

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

171. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  –1 +/
Сообщение от berium (?), 25-Янв-24, 05:39 
Нет разницы кто и кого первым приплёл.

Когда кодовая база на языке "ВАШЕНАЗВАНИЕ" достигнет объёмов кодовой базе на C/C++, тогда можно будет сделать какие-то выводы.

В будущем Rust займет какую-то нишу, но она будет существенно ниже C/C++, т.к. в последние года произошло размытие проектов по разным языкам программирования, а не как в 80/90-ых выбор между пятеркой языков, из которых два лидировали с колоссальным отрывом.

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

179. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от Советский инженер (ok), 25-Янв-24, 10:30 
>Нет разницы кто и кого первым приплёл.

разница есть. потому что такая ошибка, как описана (креш на некорректных входных данных), должна выявляться на этапе тестирования, которого, очевидно нет. и да, язык программирования тут уже ничего не исправит, просто кодеркам похер на качество.

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

193. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от Совершенно другой аноним (?), 25-Янв-24, 13:06 
>>Нет разницы кто и кого первым приплёл.
> разница есть. потому что такая ошибка, как описана (креш на некорректных входных
> данных), должна выявляться на этапе тестирования, которого, очевидно нет. и да,
> язык программирования тут уже ничего не исправит, просто кодеркам похер на
> качество.

Тесты у них есть, как минимум с 1993 года. Ошибка была внесена в coreutils 9.2 (2023-03-20). Очевидно, именно эта ситуация не тестируется.

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

197. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от Советский инженер (ok), 25-Янв-24, 18:22 
>Тесты у них есть

ага, есть но мягкий ...

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

194. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."  +/
Сообщение от Аноним (194), 25-Янв-24, 13:27 
> Сишка - сложный системный язычок, чтобы на нём писать, погроммист должен 150 раз обдумать поведение каждой строчки на выход за пределы, переполнение, нулевые указатели-сегфолт, деление на ноль и т.д. и т.п.

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

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

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

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




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

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