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

"Уязвимости в 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.ru/opennews/art.shtml?num=62037
Ответить | Правка | Cообщить модератору

Сообщения

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

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

	6. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+6 +/–
	Сообщение от Ivan_83 (ok), 12-Окт-24, 16:27
	Потому что мир так устроен. Когда авторы тратят годы чтобы реализовать всё своё про них говорят что у них NIH синдром и они зря тратят время, а когда авторы берут готовые либы и склеивают на изоленту в новый продукт за два вечера - то случается вот такое. Из того что в новости перечислено - там эта либа много где просто на переферии для чего то не нужного используется.
	Ответить | Правка | Наверх | Cообщить модератору

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

	26. "Уязвимости в Libarchive, приводящие к повреждению памяти"	–1 +/–
	Сообщение от Ivan_83 (ok), 12-Окт-24, 22:09
	Не опциональная не значит что оно там прямо все данные через себя прогоняет.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+2 +/–
	Сообщение от Аноним (11), 12-Окт-24, 17:15
	проще взять готовую библилотек, разрабы которой годами ее вылизывали, чем писать с нуля функции чтения-создания каждого формата архива, там работы на годы и требования к пониманию нескольких огромных разделов математики + численных методов. А затем это все еще и оптимизировать надо. И послне этого всего ошибок будет ничуть не меньше. а в Libarchive вот еще одним багом стало меньше.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	12. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (4), 12-Окт-24, 17:24
	Нет, проще пайп в реальные утилиты формата вместо чёрного ящика костылей с троянами.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+1 +/–
	Сообщение от neo one (?), 12-Окт-24, 18:43
	>проще пайп в реальные утилиты формата вместо чёрного ящика костылей с троянами. бро, ты не в ту сторону воюешь. как раз утильки от вендора это кривые черные ящики, а Libarchive бери и ковыряй на здоровье. причем читал обсуждения например unrar 5й версии представляет из себя полную наркоманию, которую мало кто из опенсорсников решается расковыривать. а опенсорсники хоть немного о качестве кода думают
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (4), 12-Окт-24, 19:15
	Сабж в любом случае задействует эти "кривые черные ящики".
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (31), 13-Окт-24, 01:12
	Это не так, сабж не использует unrar. https://github.com/libarchive/libarchive/issues/1028#issueco...
	Ответить | Правка | Наверх | Cообщить модератору

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

	25. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+1 +/–
	Сообщение от Аноним (-), 12-Окт-24, 21:16
	И чо, много наковыряли? Уязвимость тихо и незаметно добавили в коммите "support rar filters" Oct 4, 2021 github.com/libarchive/libarchive/commit/01a2d329dfc71741892e2b590cf9fb25092474a0 Это было целых 3 года назад. И куда смотрела тыщща глаз все это время? Теперь ее убрали как не нужную. Заодно пофиксиили еще "более десятка ошибок". Ну типа "мы стараемся!"
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	34. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+3 +/–
	Сообщение от arisu (ok), 13-Окт-24, 02:34
	тыша глаз смотрели на тебя. ждали, пока ты соизволишь поделиться тайным знанием. а ты вместо этого стоял в розовых плавках весь красивый такой.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 14-Окт-24, 15:00
	https://github.com/libarchive/libarchive/issues/1028#issueco... ну вот вам и формальная верификация, где она? вот от таких "own implementation" и спасет от части, хотя кому я это говорю? Бекдорщикам не сдалась эта верификация.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (-), 14-Окт-24, 15:11
	> https://github.com/libarchive/libarchive/issues/1028#issueco... лол! спасибо за ссылку, схорнил > ну вот вам и формальная верификация, где она? Не, формальная верификация это долго и дорого Тут хотя бы не делать велосипеды и не писать овнокод. Ну и "разрабы" тоже хотят кушать, а за бекдор могут предложить немаленькие деньги
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 14-Окт-24, 15:52
	> лол! спасибо за ссылку, схорнил передано Аноним (31) > Не, формальная верификация это долго и дорого так спецификацию описывать долго, и ее делает обычно инициатор - "создатель" алгоритма, а это означает тщательность его работы, как доказательство научное. Если вы создатель алгоритма сжатия, к примеру, вы должны описать его спецификацию и предоставить методы верификации имплементации, приложить тестовые вектора и т.д. И эта работа должна быть проделана тщательно, а не на отъе**сь. > Тут хотя бы не делать велосипеды и не писать овнокод. Велосипеды делать не воспрещается, тут надо смотреть на мотив, какова цель сей затеи. Без нормальной спецификации от создателя алгоритма, мы можем быть уверенны в полной корректности реализации сего алгоритма? Ответ - нет, если этой спецификации нет. И целей то от силу три может быть (сравнивая с libunrar.a): 1) Безопасность (якобы дырявей) 2) Производительность 3) Бекдоринг. Я склоняюсь к пункту 3. > Ну и "разрабы" тоже хотят кушать, а за бекдор могут предложить немаленькие деньги Деньги то получают обычные (они (заказчики) хорошо умеют считать деньги), а вот за не послушание и срыв дедлайна - могут и уволить.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+1 +/–
	Сообщение от Ivan_83 (ok), 12-Окт-24, 22:23
	Не нужна там никакая математика кроме начальных классов школы. Вы путаете разработку архиватора и банальную инмплементацию готовых алгоритмов, тем более когда доступны референсы. Но работы реально много. С другой стороны я видел даже на вижалбейсике реализацию кучу алгоритмов сжатия.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	56. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (56), 13-Окт-24, 20:38
	Для разработки архиватора действительно хватает школьного образования, а вот для сжатия полученного архива, нужны серьезные знания дискретной математики.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Ivan_83 (ok), 14-Окт-24, 16:47
	Сабжевая либа - просто сборник алгоритмов в одном месте с одним API, подобно OpenSSL для крипты. Чтобы накатать такую либу не нужно парится с разработкой алгоритмов, нужно брать готовое и клеить на изоленту.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (22), 12-Окт-24, 19:08
	Потому что авторы - жмоты, заплатить за аудит и вылизывание libarchive.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	72. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 14-Окт-24, 14:57
	> заплатить за аудит и вылизывание libarchive. так чего там вылизывать, это банальная обвязка, студент и то лучше напишет, а тут десятки багов и цель их одна - бекдоринг.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от arisu (ok), 14-Окт-24, 19:21
	> и цель их одна - бекдоринг. где пруфы, билли?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (86), 14-Окт-24, 22:28
	Я правильно понял, авторы пишут полезный инструмент и делятся им с другими - это жмоты, кто-то только гадит и вымогает вознаграждение - это герой-спаситель?
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	89. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от arisu (ok), 14-Окт-24, 23:26
	> Я правильно понял, авторы пишут полезный инструмент и делятся им с другими > - это жмоты, кто-то только гадит и вымогает вознаграждение - это > герой-спаситель? да. это реалии современного «опенсорца». внезапно — авторы свободного софта оказываются всем вокруг должны, и всё равно они по жизни бракоделы, ату их.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (23), 12-Окт-24, 19:13
	> Не сказать, что удивлён, это известная закладочка. Ты о языке C?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	48. Скрыто модератором	+/–
	Сообщение от Аноним (48), 13-Окт-24, 15:50
	Как говорится, у кого что болит.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 14-Окт-24, 14:55
	> Не сказать, что удивлён, это известная закладочка. любая такая обвязка форматов и есть бекдоринг чистой воды.
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	81. Скрыто модератором	+/–
	Сообщение от arisu (ok), 14-Окт-24, 19:20
	женя, да залогинься уже и излей свою боль, что ты под анонимом-то?
	Ответить | Правка | Наверх | Cообщить модератору

7. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+1 +/–
Сообщение от Аноним (7), 12-Окт-24, 16:43
В который раз. Но выкинуть этот libarchive к сожалению нельзя - от него всё подряд зависит
Ответить | Правка | Наверх | Cообщить модератору

	9. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Герострат (?), 12-Окт-24, 16:59
	В генте можно выкинуть
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Fracta1L (ok), 12-Окт-24, 22:22
	Нельзя.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Zenitur (ok), 14-Окт-24, 08:56
	cmake зависит. Что-нибукдь ещё зависит?
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

10. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+6 +/–
Сообщение от randomize (?), 12-Окт-24, 17:03
> более десятка ошибок, приводящих к выходу за границы буфера, обращению к уже освобождённой памяти или целочисленным переполнениям Как же это достало-то уже... Каждый раз одно и то же.
Ответить | Правка | Наверх | Cообщить модератору

13. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
Сообщение от seyko (??), 12-Окт-24, 17:37
Так в чём всё таки проблема? Ну вот, например я, напишу прогу, делающую тоже самое  Всё? Я уже могу взломать систему и получить root?
Ответить | Правка | Наверх | Cообщить модератору

14. Скрыто модератором	+4 +/–
Сообщение от Аноним (-), 12-Окт-24, 17:43
Так-так-так, что у нас тут? > более десятка ошибок, приводящих к выходу за границы буфера, обращению к уже освобождённой памяти или целочисленным переполнениям ̶т̶и̶ч̶н̶ы̶е̶ незначительны ошибки ̶о̶в̶н̶о̶я̶з̶ы̶ч̶к̶о̶в̶  классических языков программирования для которых достаточно программистов в̶о̶о̶б̶щ̶е̶ ̶б̶е̶з̶ ̶м̶о̶з̶г̶о̶в̶ масксимальноц компетенции Но это не страшно, все мы ошибаемся! некоторые правда делают одни и те же ошибки и года в год, но надеются что в след раз получится по другому... "я тебе говорил что такое безумие?" (с)
Ответить | Правка | Наверх | Cообщить модератору

	32. Скрыто модератором	+4 +/–
	Сообщение от Аноним (32), 13-Окт-24, 01:30
	Ты приглашаешься переписать эту библиотеку на всеми любимом безошибочном языке. Но что-то мне подсказывает, что ничего писать на нем ты не будешь, как и 99% его фанатов.
	Ответить | Правка | Наверх | Cообщить модератору

	37. Скрыто модератором	+/–
	Сообщение от arisu (ok), 13-Окт-24, 02:37
	он бы с удовольствием, но у него ферма в пийсят серверов ещё «приветмир» собирать не закончила.
	Ответить | Правка | Наверх | Cообщить модератору

	46. Скрыто модератором	+/–
	Сообщение от Аноним (-), 13-Окт-24, 12:09
	> Ты приглашаешься переписать эту библиотеку на всеми любимом безошибочном языке. Т.е я получил уни-кальное предложение забесплатно поработать в пользу бесполезного и неблагодарного сообщества? > Но что-то мне подсказывает, что ничего писать на нем ты не будешь, как и 99% его фанатов. И.. ты абсолютно прав! Я ценю свое время и труд, так что пусть такими проектами занимаются невымершие немамонты. Лучше я проведу лишние часы с семьей и детьми.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	50. Скрыто модератором	+/–
	Сообщение от Аноним (48), 13-Окт-24, 15:53
	Но зачем же ты отрываешь от своей семьи драгоценное время, затраченное на написание бессмысленных токсичных комментариев?
	Ответить | Правка | Наверх | Cообщить модератору

	54. Скрыто модератором	+/–
	Сообщение от Аноним (-), 13-Окт-24, 16:46
	> Но зачем же ты отрываешь от своей семьи драгоценное время, затраченное на > написание бессмысленных токсичных комментариев? Ты это серьезно? Сравниваешь минуту на написание коммента и сотни часов на ковыряние в либе?
	Ответить | Правка | Наверх | Cообщить модератору

	60. Скрыто модератором	+/–
	Сообщение от arisu (ok), 13-Окт-24, 20:55
	> Но зачем же ты отрываешь от своей семьи драгоценное время, затраченное на > написание бессмысленных токсичных комментариев? семья у него воображаемая, подождёт, ничего с ней не случится.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	59. Скрыто модератором	+/–
	Сообщение от arisu (ok), 13-Окт-24, 20:53
	> Т.е я получил уни-кальное предложение забесплатно поработать в пользу бесполезного и неблагодарного > сообщества? странно. вот когда ты ругаешь авторов, что они тебе хорошо не делали — так тебя частью сообщества быть устраивает. а когда есть перспектива, что так ругать будут тебя — то сразу не устраивает. а что случилось?
	Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

15. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
Сообщение от Аноним (15), 12-Окт-24, 17:44
Потому что нечего использовать rar? Кому он вообще всrarлся?
Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
Сообщение от Аноним (17), 12-Окт-24, 17:57
Криокамеры дали течь. https://github.com/libarchive/libarchive/releases 3.7.5 вышла 14 сентября. 3.7.6 вышла 23 сентября.
Ответить | Правка | Наверх | Cообщить модератору

	19. "Уязвимости в 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)))
	Ответить | Правка | Наверх | Cообщить модератору

21. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
Сообщение от Аноним (21), 12-Окт-24, 18:54
> вызваны отсутствием проверки Фиксы как всегда шикарны +    if (src >= dst) +         return 0; +    if (src >= dst) +         return 0; Не, ну а фигли проверять входные данные)) Настоящие погромисты и так знаю что там все правильно)))
Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от arisu (ok), 13-Окт-24, 02:41
	а ты всё это видел, но сидел и молчал. или нет, или ты в принципе ничего никогда не писал, тебе просто очень хочется почувствовать себя Шибко Умным? так ты, главное, никогда ничего писать и не начинай. а то потом другой аноним так же над тобой смеяться будет. а когда кода нет — то и смеяться не над чем. удобно.
	Ответить | Правка | Наверх | Cообщить модератору

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

	58. "Уязвимости в Libarchive, приводящие к повреждению памяти"	–1 +/–
	Сообщение от arisu (ok), 13-Окт-24, 20:52
	какой ты умный, это просто нечто. повторяю предложение показать как надо. а то что-то у тех, кто громко за Дейкстру и доказательства топит, обычно ни одной реальной рабочей программы нет. прискорбно то, что в целом-то я с тобой согласен.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 13-Окт-24, 23:16
	> кто громко за Дейкстру и доказательства топит, обычно ни одной реальной рабочей программы нет. А вы задавались вопросом почему нет? > повторяю предложение показать как надо а кто вас слушать будет? думаете интел вас послушает когда вы ему скажите, что модель фон-Неймана - гамно?
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от arisu (ok), 13-Окт-24, 23:29
	> А вы задавались вопросом почему нет? потому что Дейкстра был практиком, а его фанаты-последователи все теоретики, и практики очень боятся. ибо говорить про Дейкстру они умеют, а вот приенять методы математического доказательства программ — нет. начнут что-то делать — конфуз получится. >> повторяю предложение показать как надо > а кто вас слушать будет? уж точно не астронавты-теоретики. они кроме себя всё равно никого не слышат.
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 14-Окт-24, 14:54
	> а его фанаты-последователи все теоретики, и практики очень боятся а зачем верифицировать обвязку? libarchive - обвязка. И как выше первый комментатор указал, эти обвязки создаются с целью бекдоринга и не более.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от arisu (ok), 14-Окт-24, 19:10
	я никак не могу понять: это два проприетарщика, или один в двоих играет. да, милый, да, при отсутствии софта под свободной лицензией оный софт создаётся исключительно для бэкдоринга. в проприетарном-то софте никогда никаких бэкдоров, и создаётся он от большой любви к людям.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 14-Окт-24, 22:13
	> я никак не могу понять: это два проприетарщика, или один в двоих играет Анонимы маркируются по номеру в скобках, вот я тут - Аноним (73), и мои коменты под номером (73), но ток в этой теме, в других по разному. > при отсутствии софта под свободной лицензией оный софт создаётся исключительно для бэкдоринга нет, никто за лицензию не говорил. > в проприетарном-то софте никогда никаких бэкдоров, и создаётся он от большой любви к людям. Если человек утверждает, что его софт без бекдоров, он предоставляет спецификацию для проверки, помимо исходных текстов, в случае с проприетарным софтом. Никто не пишет софт "от большой любви к людям", все это бред. пс: Кстати за Женю, он как минимум предлагает эту верификацию, а Дядя Сэм прекрасно понимает, что такой софт должен быть "своим". Вон даже глазки на реальный бекдоринг от еврейского краудстрайка закрывает. Надо же виртуальную машину пихнуть как модуль ядра.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от arisu (ok), 14-Окт-24, 23:14
	> нет, никто за лицензию не говорил. конечно, не говорил. если вдруг начать говорить про лицензию — то может получиться неудобненько: внезапно обнаружится причина, по которой пришлось писать свою реализацию. > Если человек утверждает, что его софт без бекдоров, он предоставляет спецификацию для > проверки, помимо исходных текстов, с какого испугу? исходные тексты и есть спецификация, просто представленая в машинообрабатываемом виде. этого вполне достаточно для проверки утверждения о бэкдорах. более того: это *единственный* валидный метод такой проверки.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 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 > этого вполне достаточно для проверки утверждения о бэкдорах а, что кто-то признался хоть раз, что он внедрил бекдор? Любой баг - бекдор, вы мне не докажите, что ваши намерения были самые благие, и что это не бага, а фича. > более того: это *единственный* валидный метод такой проверки и какие данные я должен подавать на вход алгоритму, чтобы понять корректность его работы? у гадалки взять эти данные?
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от arisu (ok), 15-Окт-24, 04:08
	> а то есть, лицензия не позволяет использовать чужой (оригинальный) код (алгоритм), и > это вынуждает писать собственную имплементацию, а что в итоге? некорректная имплементация > (баги, считай бекдор), кому тут спасибо говорить за такое "доброе дело"? женечке рошалю. > А что делать если еще покрыты патентами? придумывать альтернативу "кривую"? вот такой он — дивный современный мир. >> с какого испугу? исходные тексты и есть спецификация, просто представленая в машинообрабатываемом виде. > чьи исходные тексты, автора алгоритма или очередного "недоимлементатора"? ты даже не знаешь, что проверять собрался, что ли? > к прочтению: какая связь? >> этого вполне достаточно для проверки утверждения о бэкдорах > а, что кто-то признался хоть раз, что он внедрил бекдор? Любой баг > - бекдор, вы мне не докажите, что ваши намерения были самые > благие, и что это не бага, а фича. я понимаю, что ты не в курсе, но цель проверки на бэкдоры — доказать их отстутсвие, а не обвинить автора в наличии. >> более того: это *единственный* валидный метод такой проверки > и какие данные я должен подавать на вход алгоритму, чтобы понять корректность > его работы? у гадалки взять эти данные? а, то есть, читать исходник не предполагается? отличная проверка. ты же сам про бэкдоры начал. ты, наверное, удивишься — но проверка на бэкдоры не имеет никакого отношения к проверке на корректность реализации алгоритма. берём исходник, доказываем, что он не делает ничего, что могло бы привести к компрометации системы. или ты проверку на бэкдоры фузингом делать собрался? впрочем, я не удивлюсь.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Уязвимости в Libarchive, приводящие к повреждению памяти"	+/–
	Сообщение от Аноним (73), 15-Окт-24, 16:17
	> вот такой он — дивный современный мир. ясно > ты даже не знаешь, что проверять собрался, что ли? спека где? > какая связь? в смысле какая связь, мы о чем говорим? > я понимаю, что ты не в курсе, но цель проверки на бэкдоры — доказать их отстутсвие, а не обвинить автора в наличии. не я доказываю (proving), я проверяю доказательство (verifying), доказательство предоставляет "имлементатор". И при выявлении бага, что есть несоответствия спецификации, делаем вывод - бекдор! Страшнее не выявление бекдора в имплементации, а его закладка в саму спеку, а тут то знания по серьезней нужны в предметной области. > а, то есть, читать исходник не предполагается? отличная проверка. проверка кода и его тестирование не имеет отношение к корректности кода согласно спецификации. Спецификация говорит, что надо делать, а не как надо делать. > удивишься — но проверка на бэкдоры не имеет никакого отношения к проверке на корректность реализации алгоритма ну конечно не имеет, щассс, вот именно, что корректность имеет прямо таки прямое отношение к бекдорингу. Есть спека (незабекдоренная) и необходимо ее имплементировать, потом проверяют на корректность. После проверки, делается вывод. Бекдор по сути это поведение которое не описано в спеке. И это поведение не обязательно должно быть явное, в случае с багами это может быть и неявное, что приводит к двойному пониманию. Вы в любом случае будете отрицать явного бекдора ссылаясь на баг, но баг по сути это нарушение спеки, что не допустимо. > берём исходник, доказываем, что он не делает ничего, что могло бы привести к компрометации системы лол, "ничего не делает" - в системе А, но может делать в системе Б. И это "компрометации системы" понятие еще должно быть определено, как в спеке описано эта "компрометации". > или ты проверку на бэкдоры фузингом делать собрался? впрочем, я не удивлюсь. А что у вас там в спеке описано? А чем фаззинг отличается от тестовых входных данных?
	Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимости в Libarchive, приводящие к выходу за границы буфе..."	+/–
Сообщение от Аноним (47), 13-Окт-24, 14:12
Что вообще такого страшного в выходе за границы массива? Ну запортишь ты себе память, ну скрашится твоя программа. Дальше что?
Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимости в Libarchive, приводящие к выходу за границы буфе..."	+/–
	Сообщение от Аноним (48), 13-Окт-24, 15:57
	Пока есть кому зарепортить и исправить - ничего страшного, обычный процесс. Проблемы начинаются когда вместо написания кода начинают искать "волшебную пулю".
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимости в Libarchive, приводящие к выходу за границы буфе..."	+/–
	Сообщение от Аноним (-), 13-Окт-24, 16:37
	> Что вообще такого страшного в выходе за границы массива? > Ну запортишь ты себе память, ну скрашится твоя программа. Так это шикарно если она закрашится. Так оно и должно быть. Но вот проблемка как раз в том, что прога обычно не крашится. Или таки крашится, но настолько редко, что никто не парится. > Дальше что? Зато подобрав входные данные и правильно испортив память ты можешь выполнить действия, которых не было в исходном коде. Напр. прочитать что-то из файла и отправить куда нужно. Или воспользоваться другой уязвимостью для повышения привилегий до рута. Почитай или посмотри пояснения про arbitrary code execution. Там на пальцах объясняют как оно происходит. Вот наверное самый простой и при этом самый шикарный пример пример "типикал сишной дыры" opennet.ru/opennews/art.shtml?num=43536 Ты 28 раз нажимаешь BackSpace, выходишь за границы буфера, затираешь нужные данные в стеке и вуаля - заходишь без пароля на чужой комп.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	55. "Уязвимости в Libarchive, приводящие к выходу за границы буфе..."	+/–
	Сообщение от Ivan_83 (ok), 13-Окт-24, 20:17
	Хватит уже банальщину писать, есть w^x, ASLR и много всего интересного.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от arisu (ok), 13-Окт-24, 20:58
	> Хватит уже банальщину писать, есть w^x, ASLR и много всего интересного. есть, есть. попытка заменить рабочий мозг костылями. успех начинания довольно очевиден.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Уязвимости в Libarchive, приводящие к выходу за границы буфе..."	+/–
	Сообщение от Аноним (47), 14-Окт-24, 03:16
	>Зато подобрав входные данные и правильно испортив память ты можешь выполнить действия, которых не было в исходном коде. А при чём тут Си? Это вопрос должен быть адресован ld-linux.so и формату elf. Код лежит в секции text, с чего бы вдруг код не из секции text стал исполняться? Дальше, чаще всего выход за границы массива с перезаписью RET происходит в случае, когда массив лежит на стеке. Так вот нет никакой проблемы не класть массивы на стек _никогда_, всегда делать их в heap. Это совершенно не противоречит Си.
	Ответить | Правка | К родителю #53 | Наверх | Cообщить модератору

	61. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от arisu (ok), 13-Окт-24, 20:56
	> Что вообще такого страшного в выходе за границы массива? > Ну запортишь ты себе память, ну скрашится твоя программа. Дальше что? то, что на сишечке оно не падает. потому что там вообще понятия «массив» нет, и уж тем более автоматических проверок выхода индекса за диапазон допустимых значений.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	68. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от Ivan_83 (ok), 14-Окт-24, 04:32
	Там есть массивы, а проверки не нужны.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от arisu (ok), 14-Окт-24, 19:12
	> Там есть массивы. то есть, си ты не знаешь. спасибо, я понял.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от Аноним (-), 14-Окт-24, 22:04
	>> Там есть массивы. > то есть, си ты не знаешь. спасибо, я понял. Это Ваня, местная знаменитость. Я с ним как-то спорил, что в СИшке есть строки, а он меня убеждал - что нету. Я кинул цитаты из стандарта CИ, а он сказал, что "Клал я с прибором на то что кто то называет стандартом" [1] От такая компетентность)) Ну и он же хвастался что его поделие на СИшке во все ЭсЭнГэ работало. В такие моменты я спрашиваю у вселенной "ну за что!?" [1] opennet.ru/openforum/vsluhforumID3/134987.html#38
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от arisu (ok), 14-Окт-24, 23:17
	ну, если буквоедничать, то я тоже неправ: декларация массивов-то есть. а вот самих массивов нет. такой вот парадокс.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимости в 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. Сделано конечно через.. как всегда в общем.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от arisu (ok), 15-Окт-24, 21:58
	это они очень хотят, но array type там нет. если средствами языка это невозможно отличить от указателя — то, простите, это указатель. они там таки не очень точно говорят про объявление массива. а после объявления существование типа данных «массив» скоропостижно заканчивается. статические массивы, впрочем, являются странными кадаврами: это всё ещё обычные указатели, но `sizeof` отчего-то возвращает для них не размер указателя, а размер зарезервированой области. некоторые личности могут закричать: «так вот же они, вот массивы!» — но мы эти крики отметаем как несознательные.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от Аноним (73), 16-Окт-24, 00:33
	> но array type там нет множество множест есть составной тип array, как и struct - такой же тип данных.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	101. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от arisu (ok), 16-Окт-24, 07:12
	как я выше написал — да, был неправ, виноват.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от Аноним (102), 16-Окт-24, 09:54
	А что для тебя массив?
	Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

	75. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от BorichL (ok), 14-Окт-24, 15:35
	А что мешает написать? Си это всего лишь инструмент, а что ты на нём напишешь, полностью зависит от твоих способнотей. Тут вот 3/4 лентяев, которые хотят, чтобы оно само, типа мы тут насрём, а рантайм пусть этот кал рассортирует и уберёт.
	Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

	80. "Уязвимости в Libarchive, приводящие к выходу за границы..."	+/–
	Сообщение от arisu (ok), 14-Окт-24, 19:17
	> А что мешает написать? невозможность нормально интегрировать это в язык без модификации компилятора. > Си это всего лишь инструмент, а что ты > на нём напишешь, полностью зависит от твоих способнотей. это очень, очень плохой инструмент. так-то и кросс в ластах бегать можно, и даже со временем привыкнуть. но зачем? серьёзно, в этом хламе даже модулей нет, хотя концепция модулей была придумана задолго до сишечки. > лентяев, которые хотят, чтобы оно само и я хочу. хочу, чтобы компилятор проверял индексы. разыменования NIL. арифметические переполнения. автоматически освобождал память. у Вирта это всё много-много лет есть. вот и не пишу больше на сишечке — разве только иногда, когда у меня приступ мазохизма, и хочется выпендриться.
	Ответить | Правка | Наверх | Cообщить модератору

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

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