В выпущенном в начале сентября исправлении уязвимости в библиотеке libnv выявлена логическая ошибка, из-за которой уязвимость не устранялась должным образом и система оставалась подвержена атаке. Библиотека libnv развивается проектом FreeBSD и используется в ядре и в приложениях из базовой системы для обработки списков в формате ключ/значение и для огранизации передачи данных при межпроцессном взаимодействии. Библиотека основана на алгоритме nvlist, применяемом в проекте OpenZFS, но во FreeBSD создана собственная реализация, поэтому уязвимость не затрагивает OpenZFS...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61956
>было исправлено ещё 345Лихо. Надо полагать, что большинство связаны с сишкой. Очевидно, язык не справляется со своими задачами.
Вот это приплёл...
А, что, это не очевидно? С чем же ещё? Читайте что написано, опять и опять: "Уязвимости вызваны обращением к уже освобождённой области памяти". В Rust таких проблем нет. И не надо опять вот тут что там всё unsafe посыпано. Иногда просто нет возможности гарантировать безопасность, но есть очень большая разница когда ты сознательно делаешь opt-in и ограничиваешь область такого кода и тем когда у тебя весь код потенциально одна большая проблема с безопасностью как в случае с С/С++.Всё уже выяснили, Google вон делал исследование по поводу безопасности, там всё ясно и понятно: хочешь меньше проблем - не пиши код на Си, только фикси его, всё новое - только на Rust.
Си не уходит исключительно потому что много людей которые его уже знают и много кода написано, но это всё конечно же изменится со временем. А потом и Rust заменится чем-нибудь более продвинутым. Это называется "прогресс". 20 лет назад такие же сидели и ныли что нафиг нам питон вместо фортрана, ну и где он?
1. Rust - не прогресс.
2. Python - не прогресс.
3. Гугль думает только о собственном кармане.
4. Кому нужна повышенная надёжность - пожалуйста, используйте Redox или Ironclad (формально верифицированное ядро на Ada).
А редокс тоже формально верифицирована?
Нет. Инструменты для Rust ещё только развиваются, типа Verus
Пересмотрите бойцовский клуб на досуге, только когда они в самолёте будут беседовать про авто аварии замените это на ошибки в коде и вы всё поймёте в этой жизни.Только у фанатиков есть цель победить все ошибки и уязвимости, обычным людям надо чтобы нечто работало с минимальными затратами.
Ошибки, уязвимости - вообще не проблема, пока не случается как у краудстрайка фигня которая всё ломает.
А откуда ты узнаешь что оно вылезет для одного пользователя или для почти всех дистрибутивов?
Небось авторы CUPS тоже думали "ну написал я плохой код, ну что может случиться".А по поводу автоаварий - вон тойотовцы уже написали код абыкак - убили больше сотни человек.
Ну убили, с кем не бывает.
Теперь бери формулу из БК и считай сколько надо трупов чтобы отозвать партию определённого размера :)Вы хотите тотальной безопасности - так не бывает.
Проще застраховатся чем бесконечно вкладыватся в безопасность.
> Ну убили, с кем не бывает.
> Теперь бери формулу из БК и считай сколько надо трупов чтобы отозвать
> партию определённого размера :)
> Вы хотите тотальной безопасности - так не бывает.
> Проще застраховатся чем бесконечно вкладыватся в безопасность.ЧСХ хруст в конфигурации как тойота - не поможет вообще совсем никак. Он такое переполнение стека в системе без MMU не увидит от слова никак. А если лэйаут памяти будет делать еще и ламер, что в случае хруста куда вероятнее - там потом тоже будет знатный факапище.
От такого только комплекс мероприятий помогает. Но тойотчики ухитирлись забить на пяток правил мисры, облажаться с оценкой использования стека и сделать вообще очень много странной фигни. От которой помогает таки только хорошая взбучка руководству, чтобы не хотелось нарушать критичные правила индустрии в угоду датам релиза, радости руководил, удачным отчетам и проч.
> Ну убили, с кем не бывает.Ну так когда тебя какой-то такой же бракодел угробит, надо будет в эпитафии написать "Иван был не против, экономьте на коде и дальше"
> Теперь бери формулу из БК и считай сколько надо трупов чтобы отозвать партию определённого размера :)
Хватило 89 человек для того чтобы бракоделы заплатили 16 миллиардов долларов.
Миллиардов, не миллионов.> Вы хотите тотальной безопасности - так не бывает.
Давай выключим светофоры - они ж ограничивают водителей, а тотальной безопасности не дает.
И ПУЭ выкинем - оно не защищает на 100%, ну подумаешь кого-то єл-вом бахенет.
А проверять лекарства годами... проще на всяких Иванах проверить.Вообще странно читать от такого немолодого пользователя такой лютый бред.
> Проще застраховатся чем бесконечно вкладыватся в безопасность.
Не бесконечно. А "достаточно".
Достаточность меняется со временем, тк технологии развиваются.
Раньше "молочка из-под буренки попил и не помер - уже отлично", а сейчас "пастеризация, хранение в холодильнике".
Забавно как вы со своей шизой топите за безопасный код и даже близко не подозреваете о всех других возможностях потерять здоровье и жизнь.
Долбанутый японский регулятор может и 100500 ярдов назначать штраф, мистер Тойода просто встанет однажды и скажет: "катитесь к херам", и закроет компанию, ликвидирует так чтобы оно не возродилось, и пойдёт пить сокэ с гейшами - ему то хватит до конца жизни. И где потом будет япония с регуляторами? Что регуляторам скажут все потерявшие работу?)
Светофоры это замена регулировщика, и называются они traffic lights и оба названия подразумевают что они про управление потоками ради собственно оптимизации этих потоков а не ради безопасности. Безопасность там производный продукт.
Когда это всё появилось к смертям относились сильно проще.
Раст не та технология.
Языков с безопасной памятью - вагон и тележка, и возрастом они все сильно старше раста.
Все кому было надо - уже давно в безопасности, либо используя ЯП либо практики типа мисра.
Но теперь появились растисты и мир оказался в опасносте.
> Забавно как вы со своей шизой топите за безопасный код и даже близко не подозреваете о всех других возможностях потерять здоровье и жизнь.Чувак, сейчас в мире куча стран перебрасывается ракетами, бомбами, а на горизонте маячит перспектива мировой (возможно ядерной).
Но это не значит, что надо писать овнокод и делать свою работу тяп-ляп.
> Долбанутый японский регулятор может и 100500 ярдов назначать штраф,Регулятор был американский)
> мистер Тойода просто встанет однажды и скажет: "катитесь к херам", и закроет компанию, ликвидирует так чтобы оно не возродилось, и пойдёт пить сокэ с гейшами - ему то хватит до конца жизни.
А должен был сделать харакири, тк в японской культуре фигово делать работу это позор.
> И где потом будет япония с регуляторами? Что регуляторам скажут все потерявшие работу?)
Думаешь не найдется того, кто захочет занять его нишу? Свято место пусто не бывает.
Придет на его место какой-то Яцизаши-сан, который решит "овнокодить не будем" и начнет выпускать что-то свое.Ты наверное из тех, кто не против когда асфальт прямо в лужу кладут или выпускают уже ржавое ведро прямо с завода.
> Светофоры это замена регулировщика, и называются они traffic lights и оба названия подразумевают что они про управление потоками ради собственно оптимизации этих потоков, а не ради безопасности. Безопасность там производный продукт.
Стоп-стоп, если у тебя столкнутся два авто или, еще хуже, поезда - то будет существенный экономический ущерб.
> Когда это всё появилось к смертям относились сильно проще.
Угу, в стиле "помер маским, ну и №№№ с ним".
Некоторые до сих пор так относятся, ну типа "1% это не много".
Но опускаться в средневековье хочется не всем людям)> Раст не та технология.
"Та или не та" решаю не я и не ты.
Те кому оно нужно будут применять, даже если тебе это не нравится.> Языков с безопасной памятью - вагон и тележка, и возрастом они все сильно старше раста.
Примеры в студию. Желательно без GC.
Я могу вспомнить только ровестницу C/C++ - ADA, но там надо думать, а на си - нет.> Все кому было надо - уже давно в безопасности, либо используя ЯП либо практики типа мисра.
Мисра это классно, но написать что-то большое без динамических аллокаций будет очень-очень сложно.
> Но теперь появились растисты и мир оказался в опасносте.
Бери больше! Голактика в опасности (с)
Вы со своей фиксацией на программных деффектах как псих который готовится к нашествию динозавров или вечно опасающийся что на него лично упадёт микрометеорит (1 зафиксированный случай за историю).
А если на горизонте маячит вымирание - то стоит расслабится и занятся чем то приятным в последние дни.
"Carol and the End of the World" вам в помощь для прочистки мозгов.
> Ты наверное из тех, кто не против когда асфальт прямо в лужу кладут или выпускают уже ржавое ведро прямо с завода.Я из тех кто считает что стерилизация медицинским спиртом поверхности перед укладкой асфальта - излишнее действие.
А если где то положат в лужу - то пусть потом по гарантии переделывают. Проблема же в том, что в РФии это не работает и по гарантии никто ничего не делает, а делает за зовые отдельные деньги потом. Был бы действующий механизм - никто бы в лужу не ложил.
Сколько лжи в паре предложений...> Только у фанатиков есть цель победить все ошибки и уязвимости,
Не все, а только 70%, но каких! Из-за которых 99% критических уязвимостей
> обычным людям надо чтобы нечто работало с минимальными затратами.
Так и работает с минимальными затратами и даже лучше, спроси у тех. директора гугла про разработку на расте и на плюсах (чтобы долго не искал, вот тебе коротко из речей Ларса Бергстрома: "On re-writing C++ into Rust: "in every case, we've seen a decrease by more than 2x in the amount of effort required to both build the services written in Rust, as well as maintain and update those services. [...] C++ is very expensive for us to maintain." ).
> Ошибки, уязвимости - вообще не проблема
... только для тебя. Иди ты лесом, с таким подходом. Пиши дырявые хелловроты строго для селбя, любимого, для своего локалхоста и не вылезай из будки.
Так не качайте и используйте мои хэлловорлды, тем более бесплатно, а я как писал так и буду дальше писать.
А какой справляется?
Turbopascal)
В нём тоже указатели можно.
> Очевидно, язык не справляется со своими задачами.А причем тут язык?
Тут проблемы в квалификации! Надо менять подходы.
Например, для PR в ядро, обязать чтобы код проходил стат. анализаторы, добавить фаззинг, публично осуждать бракоделов (можно взять Линуса и дать ему затачу показывать им пальцы)
Точно, забюрократизировать процесс чтобы виноватых не было, не важно что работа встанет.
У растоманов один из страхов - быть виноватым в ошибке, те понести отвественность за свои дела.
А что, задача была в безопасность? Вы, когда пишете код, сильно про безопасность думаете? Что ж вы так за безопасность переживаете? Есть примеры, когда лично ваш ПК пострадал из-за дыр в безопасности?Пс. Не к вам лично вопрос, а к обществу, которое бурно реагирует на такие новости.
> Вы, когда пишете код, сильно про безопасность думаете?думать о безопасности, задача безопасников!
У кого-то ведь в ответственности не только личные ПК с игрульками. Приходится думать.
Да. У кого-то где-то, но не у вас. Вы-то что так бурно реагируете на новости о безопасности?
Задача всегда в безопасность. Была, есть и будет.
Ваши вычислительные мощности как-то пострадали от дыр?
Это обязательно?
Что за обществу вы задаёте вопрос? Может быть вы задаёте его так называемому "сообществу"? Тогда я уверю вас, что стакан недостаточно полон, чтобы из него что-то выплёскивалось при бурлении.
Надо полагать, что большинство связаны с комитерами, коих >2000 бывает. Всех не проверишь. Наверняка, есть и от организаций с трёхбуквенными названиями.
Другой язык программирования никак не сможет проверить этих 2000 а три буквы вставят что надо на любом языке. Даже на языке жестов.
Так сам финский студент на три буквы работает.
Да, да. Хоть Гугль то почитайте.
>язык не справляется со своими задачамиЗадача Си - быть кроссплатформенным языком ассемблера для написания небольших операционных систем, как Unix. На что-то другое его создатели не нацеливали.
Ритчи и Томпсон сильно удивились когда на Си стали делать ОСы из миллионов строк кода.
> в июньском обновлении пакета с ядром 5.10 в Debian помимо CVE-2024-26808
> было исправлено ещё 345 (!) потенциальных уязвимостейМда... Знатное peшeто это ваше ядро.
Вот что бывает, когда десятилетиями омнокодят и кладут болтяру на безопасность.
Думаю что в ядре ситуация еще хуже чем в иксах))
Надо было Hurd развивать, а не вот это вот всё.
Но к большому сожалению академические мужы оказались более тщепетмльны и медлительны, чем финский скорострел. Вышло как вышло.
> к большому сожалениюна академических мужей подали в суд и затянулись эти суды на годы.
Поэтому индустрия легкого поведения побежала за скорострелом.
А не то вышло бы как паровоз в 21 веке. (Я понимаю, что вам луддитам того и надо).
Так фряха же есть более-менее окаменелая. Но почему-то вы туда не спешите.
> Надо было Hurd развивать, а не вот это вот всё.Если бы такие, как вы, принципиально отказались бы от использования небезопасных систем типа linux, и принципиально использовали бы только системы на базе хурд, то, возможно, Линус бы и задумался. Но вы ж бежите на небезопасное, делаемое тяп-ляп, которое скомпилировалось - и хорошо. Потому корпорации и не развивают хурд и подобные, а вкладываются в линукс - это проще, думать шибко не надо, и вместо программистов можно индусов нанять.
Неужели целочисленное переполнение нельзя отследить на этапе компиляции и какой-нибудь варн показать? Вроде бы проблеме сто лет в обед, а всё равно раз за разом повторяется
Некоторую часть можно компиляторами, ещё часть статическими анализаторами можно. Большую часть только при живом запуске на тестах. Что поделаешь, программирование на C и C++ -- это хотьба на канате над пропастью. Чуть зазевался -- и лови CVE.
Еще один умник. Причем здесь язык к переполнению? Лишь бы на вентилятор набросить...
Очевидно, речь про работу с создаваемыми на ходу объектами. Тогда чтобы найти, нужно разобраться как работает алгоритм. ИИ может что-то и мог бы, но это пока дорого и не совсем доступно.И когда работа с памятью идёт вручную, то все недостатки ручной работы - ошибки человека. Автоматизация убирает такое. В каких-то языках автоматика присутствует. Те языки часто хейтят.
А при том.
Берем какой-то безопасный язык, например ADA-Spark и смотрим их доку.
docs.adacore.com/spark2014-docs/html/ug/en/source/overflow_modes.html
Ого сколько тут всего интересного О_О
Но самое главное - однозначного!
Тут нет сишного овна типа "мы тут хз как сложить два числа, пусть компилятор думает, он же умный" с последущим UB.
Только ты забыл упомянуть что ада тормозит.
> Только ты забыл упомянуть что ада тормозит.Так тебе тормоза или "рут всем и пусть никто не уйдет обиженным" ?
Нафига вообще какие-то пароли, попытки изоляции и прочее, если нам главное "шобы побыстрее".
Если тормозит - просто возьмо процессор помощнее, как говорил Тодд.
Давай тогда все на питоне будем писать тогда. Раз не торопимся. Зачем ада.
Используй тогда gmplib никакого переполнения не будетЕсли где-то gmplib и что-то подобное встроено по умолчанию, то это не значит, что так надо везде
Ещё можешь флаг процессора на переполнение проверять после каждой операции
Потому что С не заморачивается такой фигнёй, он транслирует это в машинные инструкции, и как оно там на конкретном железе реализовано его не сильно колышит.
> на этапе компиляции и какой-нибудь варн показатьРазработчики на Rust сейчас: ты не поверишь!
А что в расте? Там варн? Или не даёт скомпилировать, пока явно не защитишься от переполнения? (я не знаком с растом)
А что на раст? Там каждое сложение проверяется на переполнение на этапе конь-эпиляции?
Не поверю. Человек должен решать, т.к. иногда именно отсутствия обработки переполнения и ожидается
За храстовиков все должен решать храст.
100%
Поэтому в языки добавили saturating_add, wrapping_add, overflowing_add, std::add_sat и другие аналогичные операции, которые будут гарантировано давать поведение, нужное разработчику в данном месте.
Языки не нужны код должны писать нейросети.
Ваша профессия тем более, её должны выполнять автоматы/роботы.
Нейросети должны писать код для роботов так наступит сингу... Апокалипсис.
> Неужели целочисленное переполнение нельзя отследить на этапе компиляции и какой-нибудь варн показать?Так основная проблема не с самим переполнением, а с тем, что его результат напр. используется как индекс.
И оно пишет непонятно куда, портит память, дарит рут.
Плюс переполнение signed вообще UB, т.е. одно и тоже переполнение может на разных компиляторах, с разными флагами давать разные результат.В "других языках"(с) поведение для signed переполнения зафиксировано.
А от попытки писать хз куда защищают другие механизмы.
Плюс можно включить проверку в релизе используя опцию overflow-checks (в дебаге она и так включена, но можно выключить при желании)
> а с тем, что его результат напр.вы же приводите конкретный пример поведения, я не могу понять, что ту неопределенного? У любого действия машины вполне определенное состояние, ибо машина Тьюринга в любой момент времени находится в соответствующем состоянии, и все эти состояния детерминированы. UB это чушь стандарта, это тупо не удосужились строго описать то или иное состояние.
Даже раст в продовой сборке не спасает от переполнения.
Что значит "не спасет"?. Переполнение это обычное поведение.Проблема не в переполнении, а в том что происходит после - т.е порча памяти и рут.
Пусть она выдает неверный результат - найдем на тестах (хаха, если они у нас есть) или фаззинге.
Пусть программа падает - получим логи, исправим ошибку.Но по тихому сломаться и сделать CVE - от такого точно не должно быть.
А от записи за пределы буфера спасёт?
> А от записи за пределы буфера спасёт?Да, вот от этого спасет.
Проверки на выход за границы есть в релизе по умолчанию.
Получается действительно хороший инструмент, что бы хейтеры не говорили
Нет плохой.
Почему?
Вопрос простой и наивный, но ... на все вопросы не будет ответа, надо самому прийти к ответу
Потому что раст создаёт большие проблемы чем якобы решает. А не решает потому что без ансейф раст на низком уровне где он в теории мог быть нужен в принципе ничего решить не может.
На Си тоже самое так что раст не надобен.
Спасает, если использовать функции вместо оператора +
Так и на Си так можно. Вот и выходит, что Раст не нужен, как ни крути.
Нельзя.
Данные для сложения/умножения можно прочитать из файла или получить по сети.
> вызвана недостаточной проверкой границ буфераЕсть два типа программистов на Си: первые не проверяют границы буферов, вторые проверяют, но недостаточно. Пожалуй, это всё, что нужно знать о культуре разработки на этом языке.
Таки приходите когда на вашем чуднОм языке будет написано хотя 0,001% от того что написано на С, и это будут не вариации хэлло ворлда и прочих прог на 10 строк а нечто на 50к+ строк.
Над аргументом "сперва добейся" в интернете ещё двадцать лет назад смеялись
От чего и выросло поколение не знающее матчасть.
А сейчас смеются над аргументом "сперва выучи язык, а потом его критикуй".
> на вашем чуднОм языкеЭто на каком же именно? И при чём тут другие языки к Си? Факт остаётся фактом: сишные кодеры в целом, как культурное явление, не смогли за пятьдесят лет решить типичные проблемы с менеджментом памяти.
Факт остаётся фактом: никто другой ниасилил массовое, популярное, производительное и (sic!!!) достаточно безопасное (да-да!!) ядро.Это ж вам не чистые функции в вакууме, это ж по локоть в мазуте в железных потрохах ковыряться :(
Поэтому возьмите свои замечательные и классные языки, без всяких там подколов - замечательные и классные!, и идите ка в свой юзерланд.
Как добрый старый дяденька вам советую :)
Ядро, мазут, локти — это всё понятно, к объективной реальности несовершенства оборудования вопросов нет. Почему память пятьдесят лет течёт и перезаписывается из-за буквально одних и тех же ошибок, и когда это будет исправлено на уровне культуры разработки (про тулинг и стандарт даже не спрашиваю)?
Все исправляется по мире нахождения. Используй друг языки кто тебе мешает?
Мне никто не мешает. Проблема не в моих возможностях, а в плачевном состоянии гигиены в сообществе кодеров на Си.
Это только в твоём воображении по существу нечего сказать.
> Все исправляется по мире нахождения.Вот жаль что врачи так не работают, да?
"Ой, кажется пила случайно вышла за границы черепа и мы отпилили пациенту мозг... Ну ничего, тут держалку подправим, и возможно в следующий раз повезет"
Тесты? Зачем! Мы тут все профи.> Используй друг языки кто тебе мешает?
Диды мешают. Всеми силами копротивляются добавлению раста в ядро.
Не хотят просто лишиться работы по исправлению и добавлению уязвимостей)
> Ой, кажется пила случайно вышла за границы черепа и мы отпилили пациенту мозг...Тебе переполнением буфера мозг задело?
> Диды мешают. Всеми силами копротивляются добавлению раста в ядро.
да никто вам не мешает, вы просто делать этого не хотите и/или не умеете.
Форкаете репозиторий и пишите в него на расте, но нет...
OpenVZ тянули свои патчи и их не останавливало, что они не в мэйнлайне.
wireguard переделывали несколько раз, чтобы приняли.
openvpn озадачился своим модулем -- тоже не в ядре
ntfs от paragon не хотели принимать, т.к. боялись, что никто не будет поддерживать.
zfs даже не светит в ядре оказаться, но его все равно пишут.
uksm и прочие патчи тянули или тянут насколько хватает сил и интереса.
И только расту диды мишают настолько, что даже форкать страшно
А вы errata интела, амд и прочих чипмейкеров хоть когда то читали?
Впрочем что взять с людей свято верующих что раст им может гарантировать безопасную работу с памятью, и сидящих на системах без ECC, где ровхаммер жабаскриптом из браузера делается.
> Впрочем что взять с людей свято верующих что раст им может гарантировать безопасную работу с памятьюУ гугловцев к 2022-му году (отчет на тот момент) после пары лет внедрения и использования раста в андроиде, в 1.5 млн строк нового системного кода на расте не всплыло ни одной ошибки работы с памятью. Ни одной, Карл, в полутора миллионах строк кода!
Цитата из отчета:
"...To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code..."И это за два релиза андроида!
"We don’t expect that number to stay zero forever, but given the volume of new Rust code across two Android releases, and the security-sensitive components where it’s being used, it’s a significant result."Но надо верить Ване_с_Опеннета, а не гуглу.
Новый это то что осталось или сумма со всех гит коммитов, а то может полтора ляма добавили и два убрали.А вы уже научились собирать андройд на убунте или это уже задача чересчур сложная?
(так чтобы без докеров от гугла и прочих комманд)
Этот самый гугл который в хроме ничего кроме генерации qr кода ничего больше не осилил?
Ему про полтора миллиона строк кода без единой уязвимости по памяти в андроиде, а он про "ниасилили" что-то в хроме. Вот из-за людей с таким логическим складом в голове мы и имеем тонны CVE-шек.> Этот самый гугл который в хроме ничего кроме генерации qr кода ничего больше не осилил?
Рискну предположить, что в отличие от андроида, за раст в хроме еще толком и не брались, чтобы успеть там что-то "ниасилить". И предположу дальше - гугл следует своей же заявленной стратегии - старый сишный/плюсовый код оставить и просто фиксить, а новый писать на расте или переписывать ну очень ответственные по безопасности куски, в которых вечно ошибки вылазили, типа какого-нибудь стека блютуз.
И еще предположу - гугловцев больше интересует просовываине ржавого в дырявое линукс-ядро (они робко заикались парой предложений и про такое в своем отчете), чем переписывать на ржавом в целом сильно вылизанный и причесанный хром.
> И еще предположу - гугловцев больше интересует просовываине ржавого в дырявое линукс-ядро (они робко заикались парой предложений и про такое в своем отчете), чем переписывать на ржавом в целом сильно вылизанный и причесанный хром.Хм, но зачем?
Гугл от ядра зависит, но не так сильно как какая нибудь ИБМ (красношапка).Да, по хорошему сами разрабы ядра должны были бы хотеть улучшить ядро))
У вас шизофрения какой стадии?
В диагнозе я не сомневаюсь: вы упорно отрицаете реальность в которой подавляющее большинство написано на С само или написано на производном от С продукте, работает на ОС которые написаны на С - других просто не существует (кроме как музейных экспонатов в виртуалке).
Ни один другой язык не даёт простой и понятный API для линковки с другими языками.
Вы бы сами проверились что ли… Вам про Фому, вы про Ерёму. 68-й вам пишет: Сишники пятьдесят лет подряд пишут мимо буфера, а вы ему в ответ «да ты погляди вокруг всё написано на Си». А кто с этим спорил-то? На Си и пишут мимо буфера, как и было сказано.
Так а в чём проблема то?
Это же всё работает и используется.
> У вас шизофрения какой стадии?
> В диагнозе я не сомневаюсь:О, так ты не только программист, но еще и психиатр?
А случайно "для души" не таксуете?> вы упорно отрицаете реальность в которой подавляющее большинство написано на С само или написано на производном от С продукте, работает на ОС которые написаны на С - других просто не существует (кроме как музейных экспонатов в виртуалке).
Нет, я эту рельность вижу (хотя винда написана на плюсах).
Но то что у нас есть реликты прошлого не повод за них цепляться.Весь современный мир построен рабским трудом. Все эти пирамиды, греческие и римские храмы, готические соборы и даже американские плантации.
Но это не повод сейчас вводить новое крепостное право.> Ни один другой язык не даёт простой и понятный API для линковки с другими языками.
И настолько легких уязвимостей.
Раст не замена С и даже близко к этому не подошёл, максимум он конкурент (слабенький) плюсам.
Одной якобы безопасной работы с памятью и синтаксического сахара для многопоточности очень мало чтобы метить в "системные" ЯП.
Да забудь ты про раст, что он тебе всё покоя не даёт? Очевидно, что выкинуть весь сишный код и переписать его на другом языке нереально. Очевидно так же, что никакой другой язык не способен исправить генетические проблемы Си. Вопрос остаётся всё тем же: почему культура разработки на Си такая ужасная, что кодеры пятьдесят лет делают одни и те же — буквально! — ошибки и как это исправить?
А почему вы думаете что это надо исправлять? )Вот серьёзно.
Ошибки в коде слишком редкие и слишком мало мешаются чтобы быть проблемой которую надо решать чтобы получить хоть какой то профит.
Факапы типа как с краудстрайком - слишком редкие, а всё остальное - это шум админов в курилке и не более.
ИИ сможет исправить, тогда про ошибки с памятью в Си можно будет забыть. И про Раст тоже.
>вызвана недостаточной проверкой границ буфера ...
> ...
>вызваны обращением к уже освобождённой областиМеня всегда удивляют подобные сообщения об ошибках, откуда они, кто их сделал, почему? На C и C++ программирую с 18 лет, у меня никогда не было подобных ошибок. У коллег тоже не замечал. Ошибки бывают с синхронизацией потоков, с обработкой исключений, из-за недонажатия клавиш при наборе текста, но с памятью - никогда.
Ну тут одно из двух: либо ты с коллегами решаешь тривиальные задачи не требующие сложного менеджмена памяти, либо просто врёшь.
Да, программы на С были небольшие, несколько драйверов и несколько управляющих программ для встроенных систем по 10-15 тыс. строк кода, но всё же
> несколько драйверов и несколько управляющих программ для встроенных системКак я и сказал, тривиальные задачи. Тут действительно довольно сложно налажать с управлением памятью.
Почти все задачи могут быть сведены к примитивному манагементу памяти, просто некоторые люди сильно злоупотребляют malloc()/free().
В просто плохо тестировали :)
Я тут как то писал парсер proxy proto обоих версий, и как то неожиданно много спотылкался на такой то примитивной задаче, что выяснилось когда я сам же себя ревьювил.С памятью бывают ошибки вида: маловато памяти выделил или немножко не туда записал, ASAN прекрасно такое ловит, главное дать ему такую возможность.
> ASAN прекрасно такое ловитASAN ловит только тривиальные случаи. Которые вы вряд ли допустите.
А когда для повторения нужны "специально оформленные данные", то толку от ASAN практически нет.
Для этого фазинг придумали.
Нет, он вполне себе много всего ловит, и не тривиального тоже.
> ASAN ловит только тривиальные случаи. Которые вы вряд ли допустите.
> А когда для повторения нужны "специально оформленные данные", то толку от ASAN
> практически нет.Почему же. Если все время под asan гонять - он поймает. А так то CVE и на хрусте можно вкатить. Вон там чудный crate который CVE делает исключительно safe кодом :)
> На C и C++ программирую с 18 лет"... и завтра мне исполнится 19!". Чтобы аргументировать свой опыт стажем нужно или текущий возраст указать (чтобы вычесть 18 лет) или просто назвать стаж программирования. Но вообще глупо и наивно к стажу апеллировать, ведь от человека и от решаемых задач зависит - один за 2 года добъется бОльшего, чем иной за 40 лет или один годами json-ы перекладывает или простые алгоритмы в контроллеры пихает, а другой базы данных нового типа придумывает или востребованные операционки пишет.
А про отсутствие ошибок... Это эффект Неуловимого Джо. Вы объявИте награду за найденные уязвимости в ваших поделках, как когда-то сделал Дэниел Бернштейн или как сегодня практикуют всякие гуглы, устраивая баг-баунти. Не найдут дыр - тогда и хвалитесь.
идет 3й год, а софтверных уязвимостей, способных сделать хоть что-то с моим десктопом/сервером - все так же (почти?) нет.
потому что tomoyo!
думала, кстати, попробовать портировать akari(реализуцию tomoyo, не использующую LSM) под freebsd.
после быстрого ресерча, оказалось, что это не так уж и сложно.
возможно, займусь в отпуске.
тогда можно будет и некоторые ограничения обойти(например, добавить неогран. кол-во acl-групп с именами в тексте).
А зачем?
Есть же MAC для любителей везде ограничивать и проверять.
path-based MAC'ов и тем более, MAC'ов, способных индивидуально под систему политики генерить, почти без участия пользователя - нет.
Там легко накорябать любой свой MAC.
Я так 1-2 модуля накорябал чтобы без рута давало отдельные штуки делать, кажется для сырых сокетов не руту.
зачем изобретать велосипед?
и да, Вы не МАС описали, а CAP_NET_RAW.
А я и не хотел описывать мандатный контроль доступа, хотя то что я сделал можно назвать вырожденным частным случаем оного ибо всем стало можно :)Там чуть больше:
static int
allow_socket_priv_grant(struct ucred *cred, int priv)
{
if (!allow_socket_enabled)
return (EPERM);switch (priv) {
case PRIV_NETINET_RESERVEDPORT:
case PRIV_NETINET_RAW:
case PRIV_NETINET_REUSEPORT:
case PRIV_NETINET_BINDANY:
return (0);
default:
break;
}return (EPERM);
}static struct mac_policy_ops allow_socket_ops =
{
.mpo_priv_grant = allow_socket_priv_grant
};MAC_POLICY_SET(&allow_socket_ops, mac_allow_socket,
"MAC/allow_socket", MPC_LOADTIME_FLAG_UNLOADOK, NULL);Это практически весь модуль, без чтения sysctl параметра allow_socket_enabled и инклюдов с лицензией.
Практически такой же модуль я делал для chroot от юзера, уже даже не помню зачем.И собственно моё предложение посмотреть в сторону MAC было потому что там есть всё нужное и этим легко пользоватся: можно сразу начать писать "бизнесс логику" не рыская по ядру в поисках куда бы приткнутся и не заморачиваясь тем что при обновлении системы нужно будет ребейзить свой патч каждый раз.
хм.. интересно.
надо бы по их докам поподробнее посмотреть. спасибо!
> path-based MAC'ов и тем более, MAC'ов, способных индивидуально под систему политики генерить,
> почти без участия пользователя - нет.Вам не приходило в голову что если чего-то нет и это относительно просто напрогать - то тогда это скорее всего потому что такое комбо просто лишено практического смысла?
Все эти ACL, модули и безопасности и проч имеют кое что общее. С одной стороны, админу их сложно и канительно настраивать. С другой - из эксплойтов все ваши жалкие потуги вырубаются просто влет. Ну они в силу таких соотношений и не популярны у прагматиков. Ведь по хорошему гиморно должно быть атакующим, а удобно - админам. А у вас все наоборот по сути.
> думала, кстати, попробовать портировать akari(реализуцию tomoyo, не использующую LSM)
> под freebsd. после быстрого ресерча, оказалось, что это не так уж и сложно.
> возможно, займусь в отпуске.Остался только вопрос - а зачем это все? Изоляция контейнерами и виртуалками
1) Радикальнее и спасает от большего числа факапов.
2) Многократно проще в реализации.Собственно поэтому ими все и пользуются, а вон те - удел каких-то странных личностей. А какая-нибудь рутковска делает, вот, таки, CubeOS.
1) виртуализация открывает некоторые дыры в ядре
2) Вас кто от факапов виртуалки спасет? кто от факапов инита, всех 100500 компонентов de и еще кучи системнмых сервисов?>а вон те - удел каких-то странных личностей
а вот это - фантазии анонима с опеннета. что-то не вижу я в rhel/debian/ubuntu "контейнеров и виртуализации" из коробки. а MAC - пожалуйста.
Выше, вон, еще человек писал, мол "такая связка лишена смысла".
видимо, тоже дальше домашнего компа не смотрел и про принцип работы ids не в курсе.