В написанной на языке Rust библиотеке async-tar, предоставляющей функции для чтения и записи tar-архивов, выявлена уязвимость (CVE-2025-62518, кодовое имя TARmageddon), позволяющая при распаковке специально оформленного tar-архива не только извлечь размещённые в нём файлы, но и файлы, содержащиеся во вложенном tar-архиве. Уязвимость может быть использована для обхода систем верификации архивов и распаковки файлов, для которых не выполнялась проверка...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64093
Это успех, я считаю!Кто со мной согласен - ставим плюсик
Не просто плюсик, а ++ - два плюсика.
С плюсом-плюсом XD
Наконец-то хорошая новость.
Вы не понимаете! Это другое!
А ты зоркий. Молодец, заметил - именно что другое. А то бы налетели сейчас местные сишники-ПравильныеПогромисты... Никаких тебе выходов за пределы буфера, обращения к освобожденной памяти или двойного освобождения памяти... Ну, именно того, от чего и должен спасать раст. А просто "логическая" ошибка. От которой никто не обещал (и не мог) защитить. Не в той позиции что-то там в файле считали и не проверили. Ну это те самые гугловско-майкрософтовские оставшиеся "30% ошибок", которые уже только напряжением мозгов нужно избегать.
В новости ошибка работы с памятью. Да, ошибка не с оперативной памятью.
Так выход за границы массива это логическая ошибка или нет? Если программист на Си ошибётся в размере массива, то это одно, а когда на rust ошибка с размером в структуре данных, то это другое?
Нет, дружочек, это одного рода проблемы. Да, rust спасает от ошибок с оперативной памятью, с этим спорить не буду.
> В новости ошибка работы с памятью.В новости ошибка с неправильной интерпретацией спецификации
В файле стоит
Заголовок ustar:
размер этого файла 0 байт
Заголовок PAX:
размер этого файла 20мбайтСтарая реализация приоритетной считала значение из ustar, читала 0 байт файла, и дальше читала вложенный tar как содержимое основного tar файла
А должна была читать PAX, и пропускать 20мбайт как содержимое файла
Спека говно, и точно таким же образом обсираются все реализации tar которые PAX не поддерживают.
PAX является якобы обратно совместимым, поскольку данные от него пропускаются легаси реализациями, однако он может содержать в себе копию размера, от чего и возможны такие конфликты
> Так выход за границы массива это логическая ошибка или нет? Если программист на Си ошибётся в размере массиваЧисто казуистический прием. Разницу-то в ошибках вы (да все остальные) всё равно поняли ;) Да, да, старая проблема при холиварах на этом сайте: как же обозвать все эти разные ошибки. Но тут уже более распространено мнение/определение, что есть ошибки работы с памятью (те 70% о которых гугл распинался), а есть остальные, "логические" (вот как раз когда не то или не оттуда считали или введенное значение на допустимость значений не проверили или когда уставший сонный программист знаки больше с меньше перепутал).
> Если программист на Си ошибётся в размере массива, то это одно, а когда на rust ошибка с размером в структуре данных, то это другое?
Это просто офигенно другое! И если ты этого честно не понимаешь (сомневаюсь в этом), то ты просто профнепригоден.
> Нет, дружочек, это одного рода проблемы
Не дружок ты мне пока, а тролль. И это очень разного рода проблемы.
> а есть остальные, "логические" (вот как раз когда не то или не оттуда считали или введенное значение на допустимость значений не проверили или когда уставший сонный программист знаки больше с меньше перепутал).Так выход за границы массива – это буквально всё, что вы перечислили.
Считали неопределённые данные.
Не проверили границу.
Уставший сонный программист запутался в инкременте в цикле for.
Уровень кекспертизы подоспел.
У вас есть буфер с содержимым "слово" из 5 символов.
По спецификации нужно прочитать третью букву "о", вы этого не поняли и прочитали букву в. Где здесь ошибка работы с памятью и где выходит за границы массива?
>> > а есть остальные, "логические" (вот как раз когда не то или не оттуда считали или введенное значение на допустимость значений не проверили или когда уставший сонный программист знаки больше с меньше перепутал).
> Так выход за границы массива – это буквально всё, что вы перечислили.И тут врёте и всё перекручиваете. Говорю же, казуистика. Брехня.
>Считали данные не с того места.
Где тут выход за пределы массива? Я может потом просто захочу создать массив на это считанное откуда-то число элементов. Считал какие-то данные - не значит что полез в массив по смещению или без проверки сложил значение с указателем, как в сишечке.
> Не проверили границу.
Где там про проверку _границ_ написано? Сами слово добавили и сами обвиняете? Допустимость значений - это типа "остаток на счете должен быть больше либо равен нулю". Где здесь граница? Да и в расте ты так просто и "незаметно", как в си, не выйдешь за границу массива.
> Уставший сонный программист запутался в инкременте в цикле for.
и не будешь лишний раз инкрементами в циклах баловаться - в большинстве случаев просто итераторами пробежишься и никуда за границы массива не вывалишься.
>Так выход за границы массива это логическая ошибка или нет?В новости ничего не говорится о выходе за границы массива, Rust от такого защищает.
>Если программист на Си ошибётся в размере массиваТо будет порча памяти.
>а когда на rust ошибка с размером в структуре данныхПорчи памяти не будет. Вы не сможете прочитать/записать в чужую память, только в свою.
>то это другое?Да, другое. В случае сишной уязвимости, при распаковке можно было бы вызвать условный curl | bash, здесь - только переписать файлы.
> В случае сишной уязвимости, при распаковке можно было бы вызвать условный curl | bashНельзя. С чего бы? Если речь только про ошибку при обработке данных, а не ошибке работы с ram.
> оставшиеся "30% ошибок", которые уже только напряжением мозгов нужно избегатьНу раз напряжением мозгов, то софт на расте точно обречён. Ибо в него и привлекают-то лишь всякими "вам больше не нужно думать о размере буферов и указателях", а основная масса растофанов прекращает читать на слове "думать".
Так это же замечательно, что какой-то инструмент позволяет не думать о том, что к делу не относится и сосредоточиться на прикладной задаче.Необходимость байтодрочерства и прочих ручных управлениях всем, чем можно, пошло от общей убогости компьютерных технологий прошлого (да и нынешнего), а не потому, что это исходно и хотели делать изобретая ЭВМ...
Вот сосредоточиться на прикладной задаче чет не получается.
На другой тип ошибок нужен еще один ЯП!
Может, Zig?
Хороший вариант. Вон, в Редоксе на него драйвера переписывают.
А сколько багов остаются незамеченными тупо из-за того, что раст вынуждает писать нечитаемую лапшу и раздувать изначально компактный код в несколько раз
нечитаемая она для местных сишников. А кто вкатился в эту тему и какое-то время в этом варился - заявляют, что всё прекрасно читается и понимается. Дело привычки. А техдир гугла еще и заявляет что команды, разрабатывающие проекты на расте, в два раза продуктивнее команд сиплюсплюсников. Предположу, что командная работа с "нечитаемой лапшой" не могла бы быть в два раза продуктивнее "абсолютно понятных" божественных плюсов.
Ты даже не понимаешь о чем речь, сразу видно что вкатился и варился. Когда даже книжный алгоритм приходится перелопачивать так, что он становится сам на себя не похож. Сколько из-за таких выкрутасов в коде возникает логических ошибок, невозможно и представить. Пока нормальные люди пишут код так, чтобы он был легко читаем и понятен, такие как ты варятся и вкатываются и навязывают остальным свои шизоидные извращения. Необходимы клиники для реабилитации, а еще лучше принудительные работы не связанные с компьютерами
> нормальные люди пишут код так, чтобы он был легко читаем и понятенАга, видели мы тот код "от нормальных людей"
Как тебе функция-портянка на 1000+ строк кода?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Естественно с кучей кала в виде goto - нормальной обработки ошибок ведь не завезли...И ведь это ядро! Его же пишут профи))
> Необходимы клиники для реабилитации, а еще лучше принудительные работы не связанные с компьютерами
А принудительная стререлизация, ну чтобы уже на 100% как faшики, будет?
На расте функция конечно будет не 1000 строк, размер функций же от ЯП зависит
Функцию на тысячу строк можно на любом языке написать, если что. Понимать подобный код на Rust будет также сложно как на C с goto, поскольку только в Rust и regex смысл строки может кардинально измениться всего из-за одного символа. Неудивительно, что без ИИ с ним не разобраться.
> поскольку в Rust смысл строки может кардинально
> измениться всего из-за одного символа.А теперь приведи хоть один пример когда такое может произойти
> Естественно с кучей кала в виде goto - нормальной обработки ошибок ведь
> не завезли...Вот интересно, обработка ошибок по твоему она магическая какая-то или ей занимается отдельный код? Настоящий кал - это как раз запихать в ядро код обработчиков ошибок. Задумайся почему в ядре даже стандартных библиотек нет.
> Когда даже книжный алгоритм приходится перелопачивать так, что он становится сам на себя не похож.Из этой фразы любому программисту видно, что ты алгоритм заучил, а не понял. Что однозначно определяет тебя как кодера на одном языке, которому никакая клиника уже не поможет.
Мне видно что ты читать не умеешь или какие-то ограничения в мыслительном аппарате, хз. Это где-то в первом классе у детей спрашивают про что пословица "без труда не вытащишь и рыбку из пруда" и они отвечают "про рыбку"
Так а что же ты про техдира гугла не завернул? Вот же он наверное лох, похоже из клиники для реабилитации выступал. Ну или его подло обманули агенты раста с метриками разработки, подло оболгав плюсовиков. Но я конечно поверю тебе, а не ему.> Ты даже не понимаешь о чем речь, сразу видно что вкатился и варился
К твоему сожалению, правда совсем-совсем немного, понимаю. Года три назад, не зная языка, "не вкатываясь", просто взяв примеры кода и подправив их под себя, сделал себе утилитку, работающую с внешними ресурсами (отчеты с биржи стягивает). _Почти_ всё там было понятно и аккуратно. Но да, язык учить надо. Сложное так просто не напишешь. Впрочем, как и на си.
> и раздувать изначально компактный код в несколько рази вдогонку, из соседней новости, про принятие в ядро Linux 6.18 реализации Binder IPC для Android, написанная на Rust:
"...Несмотря на продвинутые возможности и поддержку объектов со сложной семантикой владения, драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода."
Ну т.е. после этого нам _очень_ интересно твое "икспертное" мнение. Ты наверное много программ написал сразу в двух вариантах - на си и на расте, чтобы сравнить и выдать свои ценные замечания, верно? Ведь верно?
Сотни других неудобных примеров мы конечно проигнорируем, да?
Эти "сотни других неудобных примеров" только в Вашей голове? Откуда сотни примеров, если Вы и Ваши соратники утверждаете, что на расте вообще ничего не написано?
Ничего не пишут, только переписывают
> Сотни других неудобных примеров мы конечно проигнорируем, да?Какие сотни, если ты ни одного не привел?
Тебе вон дали буквально из соседней новости: кодя в Linux залит, и по сравнению с сишным стал не только проще, но и компактнее.
Скажешь что-то сожержательное?
Лапша есть и возможна на каждом языке программирования.
Скажите вот эта растовая лапша, почему она вас так цепляет? Давайте проверим.
Макфа? Есть реакция?
Есентуки?
Медведь?
Анон?
Opennet?
Может быть Дядюшка Боб? Что-то есть фиксирую, мы теряем пациента, быстрее введите ему чистый код внутревенно.
Фух вроде отпустило?А если серьезно даже не знаю чел сходи до книжного и прочитай чистая архитектура и идеальная работа.
> А сколько багов остаются незамеченными тупо из-за того, что раст вынуждает писать нечитаемую лапшуОткроем-ка осоеднюю новость: https://www.opennet.dev/opennews/art.shtml?num=64092
“Использование Rust позволило решить некоторые проблемы с которыми сталкивались разработчики Binder, включая ошибки, связанные с подсчётом ссылок, блокировками и проверкой границ, а также значительно уменьшить сложность обработки ошибок.“
Смотри, эксперт, количество ошибок при использовании Раста только убавилось. Как так?
> раздувать изначально компактный код в несколько раз
Из той же новости:
"драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода."
Смотри, Растовый код не только не раздулся по сравнению с изначальным сишным, но даже стал меньше его! Как так? 😭
> Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.Т.е проблема в том что спецификацию расширили не пойми как, включив несколько размеров для одного и того же файла, и интерпретация спеки на Rust выбрала из двух размеров не тот.
Остаётся вопрос почему размер из PAX должен иметь приоритет, ведь теперь проблема может быть обратной - реализации TAR без поддержки PAX будут читать архивы иначе чем исправленная версия.
Legacy? Не, не слышал. Конечно же, виновата спека, а не святые растоманы.
> Legacy? Не, не слышал. Конечно же, виновата спека, а не святые растоманы.Так легаси точно так же этот PAX не читают и точно так же обосрутся как и реализация на Rust)
> спецификацию расширили не пойми какТам всё ещё интереснее. Этих форматов tar было как собак нерезаных. Когда POSIX решил это дело стандартизовать, он взял два формата ustar и PAX и объединил их в один. Это не расширение, это просто какой-то толпоиппизм. Я как-то думал написать реализацию tar в образовательных целях, в рамках ознакомления с каким-то очередным язычком программирования (а заодно и с tar ознакомиться), и забил именно из-за того, что разбираться со всеми этими завихрениями дидовского мышления не было никакого желания.
Но за этим, на самом деле, прячется целая дидовская философия: работает, не трожь. Вместо того, чтобы сделать по уму, они пытаются сделать так, чтобы ничего не делать. Ну, точнее, пытались. Сейчас они наверное все на пенсии уже. Продолжают пытаться ничего не делать.
> Остаётся вопрос почему размер из PAX должен иметь приоритет
На этот вопрос ответить определённо я не могу, увы. Меня не хватило на то, чтобы изучить историю вопроса. Но это намекает на вероятный ответ (тавтологию): если для понимания современного положения дел надо изучать историю вопроса, значит это легаси, где решения определяются не здравым смыслом, а броуновским движением истории, где стандарты не создают реальность, а фиксируют её такой, какая она есть. Отливают её в граните, чтобы и потомкам наших потомков досталось бы.
Ну, это просто доказывает что программисты тупые. Какой язык им не дай, уязвимости из за неправильного подсчета они все равно умудрятся сделать.А шуму то было, мол на расте уязвимостей вообще быть не может, щас как заживем, ух!
> А шуму то было, мол на расте уязвимостей вообще быть не можетЭто от вас, сишников, этот шум. Из раза в раз. От растовиков шум - не будет _только ошибок работы с памятью_ (если не пользоваться ансейфом), а не "всех-всех-всех ошибок". И их, ошибок по памяти, таки пока что-то не наблюдается в товарных количествах, как на божественном.
Вот видите! Вот такими и должны быть баги, логическими ошибками, а не позорным переполнением буфера
> Вот видите! Вот такими и должны быть баги, логическими ошибками, а не позорным переполнением буфераФфух, мне даже как-то легче стало. Так вот какими они должны быть -- баги на расте! Если я в программе на C сделаю баг как на расте -- можно? Или это будет опять позорный дыряшечный дидовский баг? Или такие баги разрешено делать только на расте, а всем остальным -- ни-ни, не трогай, это на новый год... ой, то есть для раста? Короче, можно полную инструкцию, какими должны быть правильные баги?
Объясняю, почему так вышло - потому что в программе на Си такой баг тоже будет. Но прежде, чем поймать его, вы будете ловить переполнения буффера, двойное освобождение и прочие подобные баги памяти, и только потом логические. А тут вот ловятся сразу уже логические баги. Экономия времени
Во-первых, все баги которые могут случится на чистом Си хорошо документированы и описаны. Кто пишет на чистом Си, и реально желает избежать багов, тот их избежит. Вина в не внимательности и торопливости.>А тут вот ловятся сразу уже логические баги. Экономия времени
Дело не в характере ошибок, делов их в количестве. Не думаю, что общее количество ошибок на Расте меньше, чем в Си.
Не, ребят, сегодня не ваш день. Сначала предатели, пардон, производители процессоров вместе с Линусом в спину ударили, а теперь - вот))
Можно подробнее, пожалуйста?
> Можно подробнее, пожалуйста?
Спасибо.
Так и не ваш тоже opennet.ru/opennews/art.shtml?num=64092
Вы же не будете сравнивать какую-то либу с ядром.ЗЫ: а чего в ту тему не заглянули, проффесор? сказать нечего было?
> Так и не ваш тоже opennet.ru/opennews/art.shtml?num=64092
> Вы же не будете сравнивать какую-то либу с ядром.Спасибо, посмеялся)) Не, не поможет ;)
> ЗЫ: а чего в ту тему не заглянули, проффесор? сказать нечего было?
Потроллить на сон грядущий ;) Не всё ж вам развлекаться))
> Спасибо, посмеялся)) Не, не поможет ;)Конечно не поможет.
Если человек ставит в один ряд ядро линукс и какую-то либу от дилетантов.. то это многое о нем говорит)> Потроллить на сон грядущий
Получилось весьма уныло.
Может лучше про коммунизм? Та щиза хотя бы веселее звучит!
> Конечно не поможет.
> Если человек ставит в один ряд ядро линукс и какую-то либу от
> дилетантов.. то это многое о нем говорит)Снова посмеялся)) Не пытайтесь вырулить, говорю ж - не поможет)) Вам производители процессоров такую свинью подложили, прям загляденье.
>> Потроллить на сон грядущий
> Получилось весьма уныло.Но вы ж стриггерились - значит уже нормально ;)
Ой, как будто кто-то сейчас пользуется таким древним овном как TAR?
Оно появилось более 40 лет назад.
> Ой, как будто кто-то сейчас пользуется таким древним овном как TAR?
> Оно появилось более 40 лет назад.Архивы кода по умолчанию с GitHub в tar.gz отдаются))
> Архивы кода по умолчанию с GitHub в tar.gz отдаются))Эм... нет, это вы у себя что-то нахимичили с настройками. По умолчанию отдается zip.
github.com/torvalds/linux
Download ZIPПроверьте сами.
Раст обделался с перепмсыванием, значит, tar ненужен! Л - логика.
Сишникам совсем уже делать нечего. Нашли микроскопическую ошибку и раздули из этого целую "уязвимость".
Удалите новость, опеннет, не позорьтесь.
Нееет, выделите новость 20-м шрифтом.
Чтобы все оценили "кекспертизу" обсуждающих её сишников
Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...
>Почему программисты на Rust не могут <буквально> переписать логику с реализацией на CПотому, что тогда у них будут буквально те же самые дыры, что и на си. Ибо на си нет афинных типов данных.
И что, без аффинных типов в безопасном коде на Rust будут дыры? Вот это новость!
скиньте кто-нить этому умнику линк на словарь Ожеговаа то от его "афинных" типов у меня скоро глаз дергаться начнет
услышал где-то умное слово и носится с ним, как дурень с писаной торбой
> Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...В основном они этим и занимаются, но специфика концепции владения в расте такова, что это не всегда возможно, боровчекер не велит. Ну и код они читать не особо привыкли, "компилируется --- значит, работает", вот их девиз.
Не ошибается тот, кто ничего не делает. Давайте зароем топор войны Rust и C!
Вместе с ростом xd
Очередные неосиляторы юнит тестов. Попросили бы ИИ написать, даже самим не надо париться.
V in vibrant community means CVE
"Rust — безопасность", — говорили они.
Раст медленно но верно вытесняет сишку на обочину истории.
Обычная логическая ошибка. Сам Rust не причём.