URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 135031
[ Назад ]

Исходное сообщение
"Уязвимости в Libarchive, приводящие к повреждению памяти"

Отправлено opennews , 12-Окт-24 15:52 
В библиотеке Libarchive, предоставляющей функции для работы с различными форматами архивов и сжатых файлов, выявлены уязвимости, приводящие к выходу за границы буфера при обработке специально оформленных архивов в формате RAR. Уязвимости присутствуют в функциях execute_filter_audio (CVE-2024-48957) и  execute_filter_delta (CVE-2024-48958) и вызваны отсутствием проверки, что блок "src" может перекрывать блок "dst" в повреждённых архивах...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=62037


Содержание

Сообщения в этом обсуждении
"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 16:11 
Не сказать, что удивлён, это известная закладочка. Поэтому, я не понимаю, когда авторы сторонних проектов на неё жёстко завязываются -- у них то вроде интереса в продвижении бэкдоров нет, это не редхат и не гном.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Ivan_83 , 12-Окт-24 16:27 
Потому что мир так устроен.
Когда авторы тратят годы чтобы реализовать всё своё про них говорят что у них NIH синдром и они зря тратят время, а когда авторы берут готовые либы и склеивают на изоленту в новый продукт за два вечера - то случается вот такое.

Из того что в новости перечислено - там эта либа много где просто на переферии для чего то не нужного используется.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 16:47 
Из установленного у меня сабж неопциональная зависимость cmake и appstream-glib. Cmake это хорошее место для закладки и от appstream-glib зависит gimp (а потом спрашивают, чего это негативно относятся к стрёмным зависимостям).

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Ivan_83 , 12-Окт-24 22:09 
Не опциональная не значит что оно там прямо все данные через себя прогоняет.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 17:15 
проще взять готовую библилотек, разрабы которой годами ее вылизывали, чем писать с нуля функции чтения-создания каждого формата архива, там работы на годы и требования к пониманию нескольких огромных разделов математики + численных методов. А затем это все еще и оптимизировать надо. И послне этого всего ошибок будет ничуть не меньше. а в Libarchive вот еще одним багом стало меньше.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 17:24 
Нет, проще пайп в реальные утилиты формата вместо чёрного ящика костылей с троянами.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено neo one , 12-Окт-24 18:43 
>проще пайп в реальные утилиты формата вместо чёрного ящика костылей с троянами.

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


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 19:15 
Сабж в любом случае задействует эти "кривые черные ящики".

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 01:12 
Это не так, сабж не использует unrar.

https://github.com/libarchive/libarchive/issues/1028#issueco...


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 07:40 
С нормальным unrar линковаться нельзя, им приходится обмазываться суррогатом. Толку правда мало, всё равно файлы никакие не откроет.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 21:16 
И чо, много наковыряли?

Уязвимость тихо и незаметно добавили в коммите "support rar filters" Oct 4, 2021
github.com/libarchive/libarchive/commit/01a2d329dfc71741892e2b590cf9fb25092474a0
Это было целых 3 года назад. И куда смотрела тыщща глаз все это время?

Теперь ее убрали как не нужную.
Заодно пофиксиили еще "более десятка ошибок". Ну типа "мы стараемся!"


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 13-Окт-24 02:34 
тыша глаз смотрели на тебя. ждали, пока ты соизволишь поделиться тайным знанием. а ты вместо этого стоял в розовых плавках весь красивый такой.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 14-Окт-24 15:00 
https://github.com/libarchive/libarchive/issues/1028#issueco...

ну вот вам и формальная верификация, где она? вот от таких "own implementation" и спасет от части, хотя кому я это говорю? Бекдорщикам не сдалась эта верификация.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 14-Окт-24 15:11 
> https://github.com/libarchive/libarchive/issues/1028#issueco...

лол! спасибо за ссылку, схорнил

> ну вот вам и формальная верификация, где она?

Не, формальная верификация это долго и дорого
Тут хотя бы не делать велосипеды и не писать овнокод.

Ну и "разрабы" тоже хотят кушать, а за бекдор могут предложить немаленькие деньги


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 14-Окт-24 15:52 
> лол! спасибо за ссылку, схорнил

передано Аноним (31)

> Не, формальная верификация это долго и дорого

так спецификацию описывать долго, и ее делает обычно инициатор - "создатель" алгоритма, а это означает тщательность его работы, как доказательство научное. Если вы создатель алгоритма сжатия, к примеру, вы должны описать его спецификацию и предоставить методы верификации имплементации, приложить тестовые вектора и т.д. И эта работа должна быть проделана тщательно, а не на отъе**сь.

> Тут хотя бы не делать велосипеды и не писать овнокод.

Велосипеды делать не воспрещается, тут надо смотреть на мотив, какова цель сей затеи. Без нормальной спецификации от создателя алгоритма, мы можем быть уверенны в полной корректности реализации сего алгоритма? Ответ - нет, если этой спецификации нет. И целей то от силу три может быть (сравнивая с libunrar.a): 1) Безопасность (якобы дырявей) 2) Производительность 3) Бекдоринг. Я склоняюсь к пункту 3.

> Ну и "разрабы" тоже хотят кушать, а за бекдор могут предложить немаленькие деньги

Деньги то получают обычные (они (заказчики) хорошо умеют считать деньги), а вот за не послушание и срыв дедлайна - могут и уволить.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Ivan_83 , 12-Окт-24 22:23 
Не нужна там никакая математика кроме начальных классов школы.
Вы путаете разработку архиватора и банальную инмплементацию готовых алгоритмов, тем более когда доступны референсы.
Но работы реально много.
С другой стороны я видел даже на вижалбейсике реализацию кучу алгоритмов сжатия.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 20:38 
Для разработки архиватора действительно хватает школьного образования, а вот для сжатия полученного архива, нужны серьезные знания дискретной математики.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Ivan_83 , 14-Окт-24 16:47 
Сабжевая либа - просто сборник алгоритмов в одном месте с одним API, подобно OpenSSL для крипты.
Чтобы накатать такую либу не нужно парится с разработкой алгоритмов, нужно брать готовое и клеить на изоленту.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 19:08 
Потому что авторы - жмоты, заплатить за аудит и вылизывание libarchive.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 14-Окт-24 14:57 
> заплатить за аудит и вылизывание libarchive.

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


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 14-Окт-24 19:21 
> и цель их одна - бекдоринг.

где пруфы, билли?


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 14-Окт-24 22:28 
Я правильно понял, авторы пишут полезный инструмент и делятся им с другими - это жмоты, кто-то только гадит и вымогает вознаграждение - это герой-спаситель?

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 14-Окт-24 23:26 
> Я правильно понял, авторы пишут полезный инструмент и делятся им с другими
> - это жмоты, кто-то только гадит и вымогает вознаграждение - это
> герой-спаситель?

да. это реалии современного «опенсорца». внезапно — авторы свободного софта оказываются всем вокруг должны, и всё равно они по жизни бракоделы, ату их.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 19:13 
> Не сказать, что удивлён, это известная закладочка.

Ты о языке C?


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 15:50 
Как говорится, у кого что болит.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 14-Окт-24 14:55 
> Не сказать, что удивлён, это известная закладочка.

любая такая обвязка форматов и есть бекдоринг чистой воды.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 14-Окт-24 19:20 
женя, да залогинься уже и излей свою боль, что ты под анонимом-то?

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 16:43 
В который раз. Но выкинуть этот libarchive к сожалению нельзя - от него всё подряд зависит

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Герострат , 12-Окт-24 16:59 
В генте можно выкинуть

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Fracta1L , 12-Окт-24 22:22 
Нельзя.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Zenitur , 14-Окт-24 08:56 
cmake зависит. Что-нибукдь ещё зависит?

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено randomize , 12-Окт-24 17:03 
> более десятка ошибок, приводящих к выходу за границы буфера, обращению к уже освобождённой памяти или целочисленным переполнениям

Как же это достало-то уже... Каждый раз одно и то же.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено seyko , 12-Окт-24 17:37 
Так в чём всё таки проблема? Ну вот, например я, напишу прогу, делающую тоже самое  Всё? Я уже могу взломать систему и получить root?

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 17:43 
Так-так-так, что у нас тут?
> более десятка ошибок, приводящих к выходу за границы буфера, обращению к уже освобождённой памяти или целочисленным переполнениям

̶т̶и̶ч̶н̶ы̶е̶ незначительны ошибки ̶о̶в̶н̶о̶я̶з̶ы̶ч̶к̶о̶в̶  классических языков программирования для которых достаточно программистов в̶о̶о̶б̶щ̶е̶ ̶б̶е̶з̶ ̶м̶о̶з̶г̶о̶в̶ масксимальноц компетенции

Но это не страшно, все мы ошибаемся!
некоторые правда делают одни и те же ошибки и года в год, но надеются что в след раз получится по другому...
"я тебе говорил что такое безумие?" (с)


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 01:30 
Ты приглашаешься переписать эту библиотеку на всеми любимом безошибочном языке. Но что-то мне подсказывает, что ничего писать на нем ты не будешь, как и 99% его фанатов.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 13-Окт-24 02:37 
он бы с удовольствием, но у него ферма в пийсят серверов ещё «приветмир» собирать не закончила.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 12:09 
> Ты приглашаешься переписать эту библиотеку на всеми любимом безошибочном языке.

Т.е я получил уни-кальное предложение забесплатно поработать в пользу бесполезного и неблагодарного сообщества?

> Но что-то мне подсказывает, что ничего писать на нем ты не будешь, как и 99% его фанатов.

И.. ты абсолютно прав!
Я ценю свое время и труд, так что пусть такими проектами занимаются невымершие немамонты.
Лучше я проведу лишние часы с семьей и детьми.



"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 15:53 
Но зачем же ты отрываешь от своей семьи драгоценное время, затраченное на написание бессмысленных токсичных комментариев?

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 16:46 
> Но зачем же ты отрываешь от своей семьи драгоценное время, затраченное на
> написание бессмысленных токсичных комментариев?

Ты это серьезно?
Сравниваешь минуту на написание коммента и сотни часов на ковыряние в либе?


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 13-Окт-24 20:55 
> Но зачем же ты отрываешь от своей семьи драгоценное время, затраченное на
> написание бессмысленных токсичных комментариев?

семья у него воображаемая, подождёт, ничего с ней не случится.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 13-Окт-24 20:53 
> Т.е я получил уни-кальное предложение забесплатно поработать в пользу бесполезного и неблагодарного
> сообщества?

странно. вот когда ты ругаешь авторов, что они тебе хорошо не делали — так тебя частью сообщества быть устраивает. а когда есть перспектива, что так ругать будут тебя — то сразу не устраивает. а что случилось?


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 17:44 
Потому что нечего использовать rar? Кому он вообще всrarлся?

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 17:57 
Криокамеры дали течь.

https://github.com/libarchive/libarchive/releases

3.7.5 вышла 14 сентября.
3.7.6 вышла 23 сентября.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 18:26 
> 3.7.6 вышла 23 сентября.

Она была просто фиксом регрессий которые они наделали в 3.7.5

This release fixes a tar regression introduced in libarchive 3.7.5 (#2331, #2337)

Important bugfixes.
tar: clean up linkpath between entries (#2343)
tar: fix memory leaks when processing symlinks or parsing pax headers (#2338)
iso: be more cautious about parsing ISO-9660 timestamps (#2330)

Причем 2330 это фикс overflow)))


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 12-Окт-24 18:54 
> вызваны отсутствием проверки

Фиксы как всегда шикарны
+    if (src >= dst)
+         return 0;

+    if (src >= dst)
+         return 0;

Не, ну а фигли проверять входные данные))
Настоящие погромисты и так знаю что там все правильно)))


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 13-Окт-24 02:41 
а ты всё это видел, но сидел и молчал. или нет, или ты в принципе ничего никогда не писал, тебе просто очень хочется почувствовать себя Шибко Умным? так ты, главное, никогда ничего писать и не начинай. а то потом другой аноним так же над тобой смеяться будет. а когда кода нет — то и смеяться не над чем. удобно.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 11:15 
Не зная предметной области и не имея строгой корректной спецификации алгоритма, хоть тыща глаз пусть смотрит, толку ноль. В крипте такая же хрень, спецификация описывает одно, а имплементируют по разному, ссылаясь на производительность или константность по времени, что не описано в спецификации. Вывод, думать обо всем этом надо до написания кода, то есть на этапе строгой формализации.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 13-Окт-24 20:52 
какой ты умный, это просто нечто. повторяю предложение показать как надо. а то что-то у тех, кто громко за Дейкстру и доказательства топит, обычно ни одной реальной рабочей программы нет.

прискорбно то, что в целом-то я с тобой согласен.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 13-Окт-24 23:16 
> кто громко за Дейкстру и доказательства топит, обычно ни одной реальной рабочей программы нет.

А вы задавались вопросом почему нет?

> повторяю предложение показать как надо

а кто вас слушать будет? думаете интел вас послушает когда вы ему скажите, что модель фон-Неймана - гамно?


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 13-Окт-24 23:29 
> А вы задавались вопросом почему нет?

потому что Дейкстра был практиком, а его фанаты-последователи все теоретики, и практики очень боятся. ибо говорить про Дейкстру они умеют, а вот приенять методы математического доказательства программ — нет. начнут что-то делать — конфуз получится.

>> повторяю предложение показать как надо
> а кто вас слушать будет?

уж точно не астронавты-теоретики. они кроме себя всё равно никого не слышат.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 14-Окт-24 14:54 
> а его фанаты-последователи все теоретики, и практики очень боятся

а зачем верифицировать обвязку? libarchive - обвязка. И как выше первый комментатор указал, эти обвязки создаются с целью бекдоринга и не более.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 14-Окт-24 19:10 
я никак не могу понять: это два проприетарщика, или один в двоих играет. да, милый, да, при отсутствии софта под свободной лицензией оный софт создаётся исключительно для бэкдоринга. в проприетарном-то софте никогда никаких бэкдоров, и создаётся он от большой любви к людям.

"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 14-Окт-24 22:13 
> я никак не могу понять: это два проприетарщика, или один в двоих играет

Анонимы маркируются по номеру в скобках, вот я тут - Аноним (73), и мои коменты под номером (73), но ток в этой теме, в других по разному.

> при отсутствии софта под свободной лицензией оный софт создаётся исключительно для бэкдоринга

нет, никто за лицензию не говорил.

> в проприетарном-то софте никогда никаких бэкдоров, и создаётся он от большой любви к людям.

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

пс: Кстати за Женю, он как минимум предлагает эту верификацию, а Дядя Сэм прекрасно понимает, что такой софт должен быть "своим". Вон даже глазки на реальный бекдоринг от еврейского краудстрайка закрывает. Надо же виртуальную машину пихнуть как модуль ядра.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 14-Окт-24 23:14 
> нет, никто за лицензию не говорил.

конечно, не говорил. если вдруг начать говорить про лицензию — то может получиться неудобненько: внезапно обнаружится причина, по которой пришлось писать свою реализацию.

> Если человек утверждает, что его софт без бекдоров, он предоставляет спецификацию для
> проверки, помимо исходных текстов,

с какого испугу? исходные тексты и есть спецификация, просто представленая в машинообрабатываемом виде. этого вполне достаточно для проверки утверждения о бэкдорах. более того: это *единственный* валидный метод такой проверки.


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 15-Окт-24 02:23 
> по которой пришлось писать свою реализацию

а то есть, лицензия не позволяет использовать чужой (оригинальный) код (алгоритм), и это вынуждает писать собственную имплементацию, а что в итоге? некорректная имплементация (баги, считай бекдор), кому тут спасибо говорить за такое "доброе дело"? А что делать если еще покрыты патентами? придумывать альтернативу "кривую"?

> с какого испугу? исходные тексты и есть спецификация, просто представленая в машинообрабатываемом виде.

чьи исходные тексты, автора алгоритма или очередного "недоимлементатора"?

к прочтению:

https://en.wikipedia.org/wiki/Correctness_(computer_science)

https://en.wikipedia.org/wiki/Formal_specification

и не путать с

https://en.wikipedia.org/wiki/Language-based_security

> этого вполне достаточно для проверки утверждения о бэкдорах

а, что кто-то признался хоть раз, что он внедрил бекдор? Любой баг - бекдор, вы мне не докажите, что ваши намерения были самые благие, и что это не бага, а фича.

> более того: это *единственный* валидный метод такой проверки

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


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено arisu , 15-Окт-24 04:08 
> а то есть, лицензия не позволяет использовать чужой (оригинальный) код (алгоритм), и
> это вынуждает писать собственную имплементацию, а что в итоге? некорректная имплементация
> (баги, считай бекдор), кому тут спасибо говорить за такое "доброе дело"?

женечке рошалю.

> А что делать если еще покрыты патентами? придумывать альтернативу "кривую"?

вот такой он — дивный современный мир.

>> с какого испугу? исходные тексты и есть спецификация, просто представленая в машинообрабатываемом виде.
> чьи исходные тексты, автора алгоритма или очередного "недоимлементатора"?

ты даже не знаешь, что проверять собрался, что ли?

> к прочтению:

какая связь?

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

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

>> более того: это *единственный* валидный метод такой проверки
> и какие данные я должен подавать на вход алгоритму, чтобы понять корректность
> его работы? у гадалки взять эти данные?

а, то есть, читать исходник не предполагается? отличная проверка.

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


"Уязвимости в Libarchive, приводящие к повреждению памяти"
Отправлено Аноним , 15-Окт-24 16:17 
> вот такой он — дивный современный мир.

ясно

> ты даже не знаешь, что проверять собрался, что ли?

спека где?

> какая связь?

в смысле какая связь, мы о чем говорим?

> я понимаю, что ты не в курсе, но цель проверки на бэкдоры — доказать их отстутсвие, а не обвинить автора в наличии.

не я доказываю (proving), я проверяю доказательство (verifying), доказательство предоставляет "имлементатор". И при выявлении бага, что есть несоответствия спецификации, делаем вывод - бекдор! Страшнее не выявление бекдора в имплементации, а его закладка в саму спеку, а тут то знания по серьезней нужны в предметной области.

> а, то есть, читать исходник не предполагается? отличная проверка.

проверка кода и его тестирование не имеет отношение к корректности кода согласно спецификации. Спецификация говорит, что надо делать, а не как надо делать.

> удивишься — но проверка на бэкдоры не имеет никакого отношения к проверке на корректность реализации алгоритма

ну конечно не имеет, щассс, вот именно, что корректность имеет прямо таки прямое отношение к бекдорингу. Есть спека (незабекдоренная) и необходимо ее имплементировать, потом проверяют на корректность. После проверки, делается вывод. Бекдор по сути это поведение которое не описано в спеке. И это поведение не обязательно должно быть явное, в случае с багами это может быть и неявное, что приводит к двойному пониманию. Вы в любом случае будете отрицать явного бекдора ссылаясь на баг, но баг по сути это нарушение спеки, что не допустимо.

> берём исходник, доказываем, что он не делает ничего, что могло бы привести к компрометации системы

лол, "ничего не делает" - в системе А, но может делать в системе Б. И это "компрометации системы" понятие еще должно быть определено, как в спеке описано эта "компрометации".

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

А что у вас там в спеке описано? А чем фаззинг отличается от тестовых входных данных?


"Уязвимости в Libarchive, приводящие к выходу за границы буфе..."
Отправлено Аноним , 13-Окт-24 14:12 
Что вообще такого страшного в выходе за границы массива?

Ну запортишь ты себе память, ну скрашится твоя программа. Дальше что?


"Уязвимости в Libarchive, приводящие к выходу за границы буфе..."
Отправлено Аноним , 13-Окт-24 15:57 
Пока есть кому зарепортить и исправить - ничего страшного, обычный процесс. Проблемы начинаются когда вместо написания кода начинают искать "волшебную пулю".

"Уязвимости в Libarchive, приводящие к выходу за границы буфе..."
Отправлено Аноним , 13-Окт-24 16:37 
> Что вообще такого страшного в выходе за границы массива?
> Ну запортишь ты себе память, ну скрашится твоя программа.

Так это шикарно если она закрашится. Так оно и должно быть.
Но вот проблемка как раз в том, что прога обычно не крашится. Или таки крашится, но настолько редко, что никто не парится.

> Дальше что?

Зато подобрав входные данные и правильно испортив память ты можешь выполнить действия, которых не было в исходном коде. Напр. прочитать что-то из файла и отправить куда нужно. Или воспользоваться другой уязвимостью для повышения привилегий до рута.

Почитай или посмотри пояснения про arbitrary code execution.
Там на пальцах объясняют как оно происходит.

Вот наверное самый простой и при этом самый шикарный пример пример "типикал сишной дыры" opennet.ru/opennews/art.shtml?num=43536
Ты 28 раз нажимаешь BackSpace, выходишь за границы буфера, затираешь нужные данные в стеке и вуаля - заходишь без пароля на чужой комп.


"Уязвимости в Libarchive, приводящие к выходу за границы буфе..."
Отправлено Ivan_83 , 13-Окт-24 20:17 
Хватит уже банальщину писать, есть w^x, ASLR и много всего интересного.

"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено arisu , 13-Окт-24 20:58 
> Хватит уже банальщину писать, есть w^x, ASLR и много всего интересного.

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


"Уязвимости в Libarchive, приводящие к выходу за границы буфе..."
Отправлено Аноним , 14-Окт-24 03:16 
>Зато подобрав входные данные и правильно испортив память ты можешь выполнить действия, которых не было в исходном коде.

А при чём тут Си?

Это вопрос должен быть адресован ld-linux.so и формату elf.

Код лежит в секции text, с чего бы вдруг код не из секции text стал исполняться?

Дальше, чаще всего выход за границы массива с перезаписью RET происходит в случае, когда массив лежит на стеке. Так вот нет никакой проблемы не класть массивы на стек _никогда_, всегда делать их в heap.

Это совершенно не противоречит Си.


"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено arisu , 13-Окт-24 20:56 
> Что вообще такого страшного в выходе за границы массива?
> Ну запортишь ты себе память, ну скрашится твоя программа. Дальше что?

то, что на сишечке оно не падает. потому что там вообще понятия «массив» нет, и уж тем более автоматических проверок выхода индекса за диапазон допустимых значений.


"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено Ivan_83 , 14-Окт-24 04:32 
Там есть массивы, а проверки не нужны.

"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено arisu , 14-Окт-24 19:12 
> Там есть массивы.

то есть, си ты не знаешь. спасибо, я понял.


"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено Аноним , 14-Окт-24 22:04 
>> Там есть массивы.
> то есть, си ты не знаешь. спасибо, я понял.

Это Ваня, местная знаменитость.
Я с ним как-то спорил, что в СИшке есть строки, а он меня убеждал - что нету.

Я кинул цитаты из стандарта CИ, а он сказал, что "Клал я с прибором на то что кто то называет стандартом" [1]
От такая компетентность))
Ну и он же хвастался что его поделие на СИшке во все ЭсЭнГэ работало.

В такие моменты я спрашиваю у вселенной "ну за что!?"

[1] opennet.ru/openforum/vsluhforumID3/134987.html#38


"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено arisu , 14-Окт-24 23:17 
ну, если буквоедничать, то я тоже неправ: декларация массивов-то есть. а вот самих массивов нет. такой вот парадокс.

"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено Аноним , 15-Окт-24 15:26 
> декларация массивов-то есть. а вот самих массивов нет. такой вот парадокс.

Сначала вспомнил "*опа есть, а слова нет"))

А потом все-таки решил заглянуть в так называемый стандарт
An array type describes a contiguously allocated nonempty set of objects with a
particular member object type, called the element type.36) Array types are
characterized by their element type and by the number of elements in the array

Т.е таки не только декларация есть, но даже array type.
Сделано конечно через.. как всегда в общем.


"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено arisu , 15-Окт-24 21:58 
это они очень хотят, но array type там нет. если средствами языка это невозможно отличить от указателя — то, простите, это указатель. они там таки не очень точно говорят про объявление массива. а после объявления существование типа данных «массив» скоропостижно заканчивается.

статические массивы, впрочем, являются странными кадаврами: это всё ещё обычные указатели, но `sizeof` отчего-то возвращает для них не размер указателя, а размер зарезервированой области. некоторые личности могут закричать: «так вот же они, вот массивы!» — но мы эти крики отметаем как несознательные.


"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено Аноним , 16-Окт-24 00:33 
> но array type там нет

множество множест есть составной тип array, как и struct - такой же тип данных.


"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено arisu , 16-Окт-24 04:13 
ok, i stand corrected: на самом деле в сишечке массивы есть. доказывается объявлением двухмерного массива, например. был неправ, погорячился.

"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено Аноним , 16-Окт-24 05:09 
"статический" массив это и есть массив, буквально объект в памяти. как ты не можешь поменять адрес какой-то переменной с типом int, только объявить новую, так и с массивами. проблема с ними только потому, что система типов в Си - страшное убожество и полна хаков, и большая часть времени в стандарте была потрачена на то, чтобы код был переносим между разными тачками без дополнительных телодвижений, хотя практика использования `bool` и `limits.h` подсказывает, что впрочем то не так и много гемороя было бы включать в каждую программу какой-нибудь `stddef.h` в который все бы и положили typedef int на реальный тип, который поддерживает нижележащая тачка, а не наоборот.

"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено arisu , 16-Окт-24 07:12 
как я выше написал — да, был неправ, виноват.

"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено Аноним , 16-Окт-24 09:54 
А что для тебя массив?

"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено BorichL , 14-Окт-24 15:35 
А что мешает написать? Си это всего лишь инструмент, а что ты на нём напишешь, полностью зависит от твоих способнотей. Тут вот 3/4 лентяев, которые хотят, чтобы оно само, типа мы тут насрём, а рантайм пусть этот кал рассортирует и уберёт.

"Уязвимости в Libarchive, приводящие к выходу за границы..."
Отправлено arisu , 14-Окт-24 19:17 
> А что мешает написать?

невозможность нормально интегрировать это в язык без модификации компилятора.

> Си это всего лишь инструмент, а что ты
> на нём напишешь, полностью зависит от твоих способнотей.

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

> лентяев, которые хотят, чтобы оно само

и я хочу. хочу, чтобы компилятор проверял индексы. разыменования NIL. арифметические переполнения. автоматически освобождал память. у Вирта это всё много-много лет есть. вот и не пишу больше на сишечке — разве только иногда, когда у меня приступ мазохизма, и хочется выпендриться.