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

"Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
Сообщение от opennews (??), 30-Янв-24, 14:44
Раскрыты сведения о двух уязвимостях в поставляемом в пакете FFmpeg декодировщике формата JPEG XL, которые могут привести к выполнению кода злоумышленника при обработке в FFmpeg специально оформленных изображений. Проблемы были устранены в выпуске FFmpeg 6.1, но так как поддержка JPEG XL включена начиная с ветки 6.1, уязвимость затрагивает только системы, использующие экспериментальные сборки FFmpeg 6.1 или переносящие из них изменения... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60521
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
Сообщение от Аноним (1), 30-Янв-24, 14:44
Вот тебе и JPEG XL!
Ответить | Правка | Наверх | Cообщить модератору

	3. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–20 +/–
	Сообщение от Аноним (3), 30-Янв-24, 14:54
	FFmpeg днище, это ни для кого не секрет. У него все собственные парсеры и муксеры/демуксеры максимально кривые. Недавно вон вообще учудили и сломали поддержку вполне валидных mp4 в очередной раз, на этот раз во всех ветках сразу.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+3 +/–
	Сообщение от Аноним (12), 30-Янв-24, 15:17
	Днище не днище, а у многих пакетов в зависимостях. Без него многое не соберется.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (3), 30-Янв-24, 15:30
	Это самое страшное. И популярная альтернатива в лице VLC ещё хуже. Ну, есть полноценная альтернатива в виде gstreamer в некотором роде, но у него свои проблемы, хотя ничего ужасного кроме багов с vaapi не припомню. Разве что, в wine он почему-то не может прочитать mp4 файлы с avc+aac (судя по логам), но тут уже вопросы к wine, сам gstreamer такие файлы воспроизводит.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (24), 30-Янв-24, 15:50
	В отличие от тебя VLC и FFmpeg
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–2 +/–
	Сообщение от Аноним (3), 30-Янв-24, 16:02
	> В отличие от тебя VLC и FFmpeg Они что? Не заботятся о работе или хотя бы соответствии спецификациям, положили на пользователей? Да, всё так. Я понимаю, что авторы сами не рады популярности, но другого опенсорса у нас нет, могли бы уже не действовать "на отвали". Какой-никакой опыт можно было уже приобрести за это время. Вместо этого тратят ресурсы на срачи и драмы.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (-), 30-Янв-24, 23:14
	>> В отличие от тебя VLC и FFmpeg > Они что? Не заботятся о работе или хотя бы соответствии спецификациям, положили > на пользователей? Да, всё так. В соответствии с этими спеками в "так называемом MP4" может быть все что угодно. FYI все остальные программы и либы жрут еще меньше комбо "чего угодно" под таким соусом. Сюрприз! > не действовать "на отвали". Какой-никакой опыт можно было уже приобрести за > это время. Вместо этого тратят ресурсы на срачи и драмы. Вы в своем праве писать программы сами - и показать этим господам мастеркласс, написав либу лучше. Мы даже может быть ей пользоваться будем - если конечно у вас это получится. А если вы так не готовы - тады пишите в спортлото!
	Ответить | Правка | Наверх | Cообщить модератору

	68. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (68), 30-Янв-24, 22:40
	Как в анекдоте: "стратегию я вам рассказала, а дальше вы как-нибудь сами"
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	70. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Аноним (-), 30-Янв-24, 23:04
	> Это самое страшное. И популярная альтернатива в лице VLC ещё хуже. А самое забавное - что vlc как раз таки и сам пользуется ffmpeg'овскими либами чтобы жрать столько форматов. Представляете?! > Ну, естьполноценная альтернатива в виде gstreamer в некотором роде, но у него свои > проблемы, хотя ничего ужасного кроме багов с vaapi не припомню. Там и CVE бывают, и просто это глючная кривая байда, прибитая к гному. Ну этим ужастиком никто и не пользуется почти, кроме полутора гномопрог. И по зависимостям ему чуть не dbus надо. А ffmpeg к гному или вообще какой либо графике не привязан от слова вообще, им можно пользоваться даже в текстовых программах работающих на серваках. А теперь коронный номер. Возьмем например модный SVT-AV1. Через ffmpeg его прогнать? Да не вопрос, тот уже несколько лет сие поддерживает. А как там gstreamer поживает? А может, gstreamer сможет схарчить bink video из вон той гамесы? Ах, нет, не сможет? Ну тогда он и не конкурент этой штуке - тот же vcmi не сможет заменить ffmpeg на gstreamer даже если б захотел. > Разве что, в wine он почему-то не может прочитать mp4 файлы с avc+aac > (судя по логам), но тут уже вопросы к wine, сам gstreamer такие файлы воспроизводит. Сам gstreamer это кусок глюкала с кучей проблем которым почти никто не пользуется. Но чтобы это знать надо попытаться писать программы, или хотя-бы в их сорцы заглядывать.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

	74. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–2 +/–
	Сообщение от Аноним (3), 30-Янв-24, 23:22
	>сам пользуется Это опциональная зависимость. Кто им только не пользуется, но важен результат. Gpac вот пользуется, но у него почему-то валидные файлы, соответствующие спецификациям на выходе. Прочитать файлы правда так и не смог с багованным ffmpeg, в отличие от vlc и gstremer. >кусок глюкала с кучей проблем Каких, например? >чтобы это знать надо попытаться писать программ Я пишу программы и обрабатываю файлы на нескольких весьма разных платформах (в том числе с аппаратным ускорением), когда должен начать знать? Про тысячи недоработок и откровенных багов (многие из которых упорно отказываются исправлять) ffmpeg я вот хорошо знаю. >в их сорцы заглядывать Ты сейчас конечно же покажешь, куда посмотреть. Я вот не использовал gstreamer в своём коде, очень интересно.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+3 +/–
	Сообщение от Аноним (-), 31-Янв-24, 00:06
	>>сам пользуется > Это опциональная зависимость. Кто им только не пользуется, но важен результат. Он настолько опциональный - что я ни разу в жизни VLC без ffmpeg'ской либы не видел. Ну, наверное, его можно самому так отстроить если очень хочется, но остальные так не делают. Потому что если даже так и можно, он из всеядного универсала резко станет нафигнужной байдой играюшей полтора формата. Профачив основное достоинство. И зачем он такой кому? :) > Gpac вот пользуется, но у него почему-то валидные файлы, соответствующие > спецификациям на выходе. Я вообще не знаю что это за байда, ее в актуальном дебиане кажется нет. А gstreamer ненавижу еще с нокийского maemo где они удумали это юзать основным медийным фреймворком, и вот там я смог насладиться этой ср@нью от души. Вы когда нибудь видели пайплайн этой дряни для записи видео с камеры? А, и --help или чего там подсказываюшего HOW TO - нету. Как максимум поиском в инете найти что так можно. На этом фоне ffmpeg - очень интуитивная и хорошая программа, со встроенным хелпарем, описывающим в том числе и захват экрана и камеры. Так что научиться это делать - в 10 раз проще. > Прочитать файлы правда так и не смог с багованным ffmpeg, > в отличие от vlc и gstremer. Я хз о чем все это - у меня ffmpeg жрет все мыслимые файлы вроде. Учитывая вольность спеков MP4 контейнера я конечно не удивлюсь что что-то где-то каким-то софтом играется. Для начала одна и та же структура может быть MOV, 3GP/3G2, MP4, ISO BMFF и проч - но в мелких деталях и спеках подвидов ЭТОГО - есть "subtle differences". И там вообще-то в спеках знатный бардачелло, на память о том что изначально это - эпловский MOV контейнер в девичестве. Комитет бакланов стандартизировал, стандартизировал, да что-то настандартизировал. В перерывах между ублажением патентных троллей. >>кусок глюкала с кучей проблем > Каких, например? У меня например плеер юзавший это - при открытии некоторых файлов падал где-то в недрах его либ. Дебажить не стал, выпилив к хренам плеер и заменив на - вот - vlc который жрет все что шевелится, без таких эксцессов. Более того - ffmpeg жрет просто в разы больше форматов. Можно - вот - заставку из геруев III взять и проиграть. VCMI (альтернативный открытый движок) это кстати и делает. И даже сконвертить в другой формат если хочется. Меня это колыхало потому что в эпоху молодости и глупости я наслушался проприетариев из RadGameTools про офигенный формат, конвертнул в него несколько мувиков, СНЕС ОРИГИНАЛ, и заметил что играется оно только убогим проприетарным плеером RadGameTools'ов который вообще не кодек. А доступ к моим данным - утерян (не переснимать же мне мувик захватом экрана?). И вот потом ffmpeg это - пофиксил. За что я безмерно благодарен этим господам. Теперь я могу опять делать с МОИМИ данными то что захочу. > Я пишу программы и обрабатываю файлы на нескольких весьма разных платформах (в > том числе с аппаратным ускорением), когда должен начать знать? Про тысячи > недоработок и откровенных багов (многие из которых упорно отказываются исправлять) ffmpeg > я вот хорошо знаю. А у gstreamer вообще апи какое-то ушибленое и умеет он по сравнению с ffmpeg - по сути нифига. Фичесет очень разный. > Ты сейчас конечно же покажешь, куда посмотреть. Я вот не использовал gstreamer > в своём коде, очень интересно. Ну вон в pidgin он есть. И это 1 из причин по которым я перестал pidgin использовать, ибо по зависимостям это боль. В его кодеках постоянно CVE перли, так что когда хочет сказать как этого не бывает... кхе-кхе. Более того - в этой байде есть plugins-base, plugins-good и plugins-bad. Как вы уже поняли без -bad оно полтора формата рюхает - и общее качество кодеков и их падучесть оставляет желать много лучшего. А так посмеяться - есть плагин для - вот - ffmpeg'овских либ. На мое нескромное мнение - ffmpeg в целом намного лучше этого горбыля по поддержке форматов. И если сравнить код gstreamer в pidgin с кодом делающим примерно то же самое в libtoxcore - тут можно еще поспорить кто там хороший и плохой. Не сомневаюсь что в ffmpeg полно скелетов в шкафу и можно многое улучшить - но gstreamer вообще по сути никто кроме гномеров не юзает и лично мне с ним не везло, у меня хреновый опыт с ним.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (84), 31-Янв-24, 02:05
	>> Gpac... > Я вообще не знаю что это за байда, ее в актуальном дебиане кажется нет. Это одна из немногих прог, умеющая mpeg4 BIFS (которого нигде нету). BIFS - это такой векторный заменятор флеша, который никому не нужен. Но всё же это часть стандарта mpeg4 (part 11). ИМХО, основная задача была заменить DVD-меню. Но получилось сильно сложно и прям совсем-совсем не взлетело.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (-), 31-Янв-24, 03:28
	> Это одна из немногих прог, умеющая mpeg4 BIFS (которого нигде нету). BIFS > - это такой векторный заменятор флеша, который никому не нужен. Но > всё же это часть стандарта mpeg4 (part 11). В этом мире много странной фигни. Скажем у меня как-то был webm с "VP10". А, что, вы такого кодека то не знаете? Да и я тоже. Но был краткий миг когда из VP9 уже вырос из VP9 но еще не дорос до AV1, и вот тогда, их тулса генерила - ну вот это вот. Технически оно как бы валидная матрешка. > ИМХО, основная задача была заменить DVD-меню. Но получилось сильно сложно и прям > совсем-совсем не взлетело. ISO в последнее время что-то лажает и делает хз что и зачем, имхо. AV1 их придавил, вон вообще суетятся, форматики строгают, нафиг кому нужные, с патентами, уже штуки 3 убийц AV1 выкатили. или таки 4, со счета сбился.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 30-Янв-24, 22:58
	> FFmpeg днище, это ни для кого не секрет. У него все собственные парсеры и > муксеры/демуксеры максимально кривые. Недавно вон вообще учудили и сломали > поддержку вполне валидных mp4 в очередной раз, на этот раз во всех ветках сразу. Критикуя - предлагай. Покажи мне универсальный либ лучше, жрущий столько же форматов. А, что, его нет?! Ну тогда господа соревнуются только с секундной стрелкой и не могут быть плохими или хорошими - сравнимого референса относительно которого можно быть лучше или хуже вообще нет. А "вполне валидный mp4" очень растяжимое понятие. MP4 это лишь контейнер и там можно что угодно сделать. Сколько софта вот прям ща сможет проиграть "MP4" где в ISO BMFF файле по факту AV1 какой-нибудь? А так то - валидный файл, ISO это даже стандартизировал недавно.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	72. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–3 +/–
	Сообщение от Аноним (3), 30-Янв-24, 23:08
	А зачем? Gstreamer поддерживает все адекватные форматы контейнеров и кодеков. Толку от кривого mp4, если он не соответствует никаким спецификациям? Av1 в mp4, кстати, соответствует. Вот vp9 в mp4 уже нет. Да и зачем тебе такие битые файлы? Ты же понимаешь, что кривые нестандартные файлы в принципе существуют только из-за ffmpeg, разрабам которого плевать на валидность?
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Аноним (-), 30-Янв-24, 23:31
	> А зачем? Gstreamer поддерживает все адекватные форматы контейнеров и кодеков. Он поддерживает в разы менее форматов и вообще - кривая глючная байда под узкие нужды гномеров. И CVE в нем - на пару ffmpeg'ов хватит. Это уг настолько ужасно что им почти никто и не пользуется как раз. > Толку от кривого mp4, если он не соответствует никаким спецификациям? Ну как бы если вот реально есть файло соответствующее спекам но не играющееся - выложите его как образец, пришлите ссыль разработчикам. Не, лениво? Ну тогда и сидите с своими файлами, это ж у вас проблема а не у других ;). > Av1 в mp4, кстати, соответствует. Теперь попробуйте это, соответствующее спекам, реальному софту скормить. И сколько его уже готово сожрать такое комбо? Ffmpeg это комбо умеет вроде уже в обе стороны как раз. А gstreamer такое вообще сожрет? > Вот vp9 в mp4 уже нет. Да и зачем тебе такие битые файлы? Ты же понимаешь, > что кривые нестандартные файлы в принципе существуют только из-за ffmpeg, > разрабам которого плевать на валидность? Я понимаю что технически ISO BMFF лишь контейнер, как и AVI/MOV(который сам почти как BMFF)/Mastroska/... и технически в него можно загнать что угодно. То что наобум взятый софт сжует произвольно взятое комбо того что заявлено MP4 - ниоткуда не следует. И ISO сам виноват в этом, разведя бардак в спеках.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (115), 31-Янв-24, 18:05
	Кто тебе такое придумал? Критиковать это в первую очередь дать толчок подумать а не раскрыть тебе все карты. Да и цель уничтожить никто не отменял так что живи с этим
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	94. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–2 +/–
	Сообщение от Аноним (94), 31-Янв-24, 07:01
	> FFmpeg днище, это ни для кого не секрет. напиши своё, покажи класс. чтобы все видели, как у тебя всё работает без малейшей погрешности и с той же эффективностью. пока что ты только строчишь спам-комменты на опеннете. это как бы показатель.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	118. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (118), 01-Фев-24, 05:55
	Это днище Голливуд использует
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	123. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (3), 01-Фев-24, 10:27
	Маловероятно. Исчезающе маловероятно. Или ты про куски в продуктах адобы? Да, они вполне понимают, в каких местах ffmpeg днище и умеют экономить.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (13), 30-Янв-24, 15:21
	> Вот тебе и JPEG XL! При чем здесь JPEG XL? Сишочники где угодно int переполнят и за буфер вылезут.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	41. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (41), 30-Янв-24, 16:43
	Дак а нафига ты юзаешь этот дырявый ffmpeg? Напиши свой на безопасном языке или юзай готовый, если не способен написать свой ffmpeg без единой ошибки
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (13), 30-Янв-24, 17:35
	> Дак а нафига ты юзаешь этот дырявый ffmpeg? Напиши свой на безопасном языке или юзай готовый, если не способен написать свой ffmpeg без единой ошибки Каким образом твои умничния относятся к моему вопросу?
	Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (41), 30-Янв-24, 17:40
	Таким образом, что ffmpeg и jpegXL - это чистое байтодрочерство, где Си - идеальный выбор. Со своими борроу чекерами и прочей чепухой иди в... в веб разработку.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Аноним (-), 30-Янв-24, 18:11
	> Си - идеальный выбор. Ахаха! И как два байта отослать они вышли за пределы массива и выполнили чужой код))) Сишники даже байтодрочерство не могут сделать нормально!
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (41), 30-Янв-24, 18:29
	Фигня это все. Несмотря на эту ошибку, они смогли написать целый ffmpeg. А растаманы даже компилятор свой не написали и собирают весь свой код компилятором написанном на С++.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Аноним (65), 30-Янв-24, 19:20
	Вот опять - тебе пишут про си, а ты на раст съезжаешь. Зачем так? > А растаманы даже компилятор свой не написали Так на прекрасном с++ (причем новом! в шланге вроде с++17), а не на богомерзкой окаменелой дыряшке. Кстати, в gcc тоже куча кода на с++ и ничего, как-то сишное ядро собирает.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (-), 30-Янв-24, 23:36
	> Вот опять - тебе пишут про си, а ты на раст съезжаешь. Зачем так? Ну вы же не написали на <чем угодно> аналог ffmpeg, так что он по своему прав. >> А растаманы даже компилятор свой не написали > Так на прекрасном с++ (причем новом! в шланге вроде с++17), а не > на богомерзкой окаменелой дыряшке. А в этом саммом C++ есть те же "int" из сей дурацкие. Представляете? И вообще, C++ это superset C внезапно. С очень небольшими исключениями. Так что C++ может означать что угодно. Вплоть до откровенного си где из ++ аж // как коменты были, это у виндокодеров было популярно такое. Бывает еще "C с классами" и прочие странные штуки. > Кстати, в gcc тоже куча кода на с++ и ничего, как-то сишное ядро собирает. А еще C++ весьма растяжимое понятие включающее в себя и почти весь си.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+3 +/–
	Сообщение от Аноним (13), 30-Янв-24, 22:00
	> Таким образом, что ffmpeg и jpegXL - это чистое байтодрочерство, где Си - идеальный выбор. Со своими борроу чекерами и прочей чепухой иди в... в веб разработку. Чел, с тобой все хорошо? С какими "моими" борроу чекерами, если я о Расте даже не упоминал?
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	59. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Бывалый смузихлёб (?), 30-Янв-24, 18:06
	> при обработке в FFmpeg специально оформленных изображений > возникшем из-за отсутствия проверки превышения размера типа int Это на чём угодно может произойти
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	77. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (-), 30-Янв-24, 23:38
	>> при обработке в FFmpeg специально оформленных изображений >> возникшем из-за отсутствия проверки превышения размера типа int > Это на чём угодно может произойти Даже на хрусте в релизных билдах, что забавно. Ибо рантайм чек этого добра - очень накладное занятие. А насколько все хотели тормозные кодеки - э, а чего они тогда вопят что AV1/265/266 кодировать тормозно? Не хотите еще разика в три это дело обвалить по скорости? :)
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (94), 31-Янв-24, 07:14
	> Сишочники где угодно int переполнят и за буфер вылезут. удали всё, что написано на сях.  полностью всё. и микросхему с биосом от платы отковыряй. и все остальные, в которых есть прошивки. и процессор вытащи. и выкинь. потому как в этом всём до сих пор без сей не обходится. и жди пока всё перепишут на расте.  включая софт для микросхемной литографии. в оффлайне жди. потому что нет ни онлайна, ни системы, ни даже железа, работающих без кода, написанного на сях.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	104. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (104), 31-Янв-24, 09:50
	А чо вы хотели, там же полнота по Тьюрингу... Туда любую малварь при желании вместе с картинкой зашить можно
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

8. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–4 +/–
Сообщение от Аноним (-), 30-Янв-24, 15:06
> использованием знакового типа int64_t вместо беззнакового uint64_t Но зачем? Что они хотели выиграть таким образом? Или опять в дыряшечном стиле через отрицательные значения прокидывают ошибки?
Ответить | Правка | Наверх | Cообщить модератору

	11. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (11), 30-Янв-24, 15:16
	тяжело без математики?! :-D
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–3 +/–
	Сообщение от Аноним (3), 30-Янв-24, 15:24
	После недавней истории с mp4 я окончательно убеждён, что ffmpeg занимаются совершенно неадекватные люди. Могут ли абсолютно невменяемые сумасшедшие (почитайте комментарии на багтрекере) писать качественный код?
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	21. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от poop (?), 30-Янв-24, 15:45
	ссылку
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (3), 30-Янв-24, 15:51
	https://github.com/yt-dlp/yt-dlp/issues/8641 но насколько я понял всё серьёзнее и все ветки сломаны минорным обновлением, файлы битые и gpac не помог.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (66), 30-Янв-24, 20:08
	ffmpeg это не про качественный код, это про код, который умеет кучу всего [но с багами]. Прошу отнестись с пониманием, философски.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (71), 30-Янв-24, 23:05
	И заменить нечем?
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (66), 31-Янв-24, 19:04
	Глобально - нет, местами - можно. Понимаешь, ffmpeg - это большое дерево кода для мукса/демукса разных контейнеров, кодирования/декодирования разных аудио и видео кодеков, вагон и тележка фильтров для трансформаций, преобразований, наложения и т.п. Где-то мощней gpac (mp4box в первую очередь), где-то MKVToolNix, что-то приятней кодировать отдельными кодеками типа lame, oggenc, x264 и т.п, обработка видео и наложение фильтров интересней в условном avisynth/vapoursynth, а может сведение футажа в nle типа DaVinci Resolve. Но где у ffmpeg нет конкуретов в принципе - это как библиотека для сторонних приложений (видеоплееров в первую очередь). Заиметь поддержку сотни форматов, демукс контейнеров, декодирование аудио и видео, причём при всех обосрамсах, которые случаются с ffmpeg регулярно, это дорогого стоит. Ну и самое важное, что открытая модель разработки в случаи с ffmpeg реально играет сильно в плюс - регулярные багрепорты (в т.ч. регрессии), куча готовых заклинаний на том же stackoverflow и т.п.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 01-Фев-24, 11:14
	> Где-то мощней gpac (mp4box в первую очередь), где-то MKVToolNix, что-то приятней > кодировать отдельными кодеками типа lame, oggenc, x264 и т.п, обработка видео > и наложение фильтров интересней в условном avisynth/vapoursynth, а может сведение футажа > в nle типа DaVinci Resolve. Однако ffmpeg имеет забойное преимущество перед вон теми: на входе может быть любое что жрет ffmpeg. Попробуйте голым x264 закодировать заставку от геруев в формате bink video. А, что, лыжи резко встали на асфальт? Ffmpeg же еще и не такое суперкомбо прожует. Т.е. в принципе его можно юзать как унивесальный "any to any" конвертер. До кучи. Ну почти. Даже для не совсем видео (e.g. audio или картинки) нехило катит. Хотите пачку .png кадров в видик? Или наоборот, разобрать в стопочку картинок? Или вот - в apng анимаху? Легко. > Но где у ffmpeg нет конкуретов в принципе - это как библиотека > для сторонних приложений (видеоплееров в первую очередь). Как универсальный конвертор/ремуксер, простые операции с сегментами/времянками, добавить-убрать трек, отпроцессить технические дефекты и проч - тоже в общем то катит. При том как транскодер он на самом деле может все то же что x264, AV1 кодеры, или кто там - ибо в современных кодеках обучен сабмитить параметры key-value либе, это ничем от родной морды либы не отличается. Кроме того что этот фронтэнд жрет дофига форматов на вход. > случаются с ffmpeg регулярно, это дорогого стоит. Ну так остальные не смогли даже так. И при том числе форматов и их сложности фейлы будут у кого угодно. Тем более что спеки на MP4 контейнеры это вообще весьма забавная штука. > в плюс - регулярные багрепорты (в т.ч. регрессии), куча готовых заклинаний > на том же stackoverflow и т.п. Ну вон у тех господ какие-то фейлы с этим вышли, хотя патч тривиальный. А кривой таки походу гугол.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Аноним (85), 31-Янв-24, 02:17
	> но насколько я понял Кажется, ты ничего не понял. > gpac не помог А по *твоей* ссылке написано, что помог: "A workaround I found is to use mp4box". > файлы битые Битые файлы отдал ютуб, их скормили ffmpeg'у, он отказался их есть ("error reading header") и ничего не поломал, т.к. он не меняет файлы in-place. > сломали поддержку вполне валидных mp4 (не буду отвечать на все 10 твоих сообщений) Это ложь, судя по исправлению с "Ignoring duplicate FTYP" по твоей ссылке. Стандарт про этот Box говорит "Quantity: Exactly one". > *претензия в целом к встроенным (де)муксерам* Я не вижу проблемы муксить отдельным инструментом (mkvtoolnix, в моём случае), потому помимо не всегда хороших муксеров в ffmpeg есть куча незаменимых инструментов. То есть незаменимых конвейерами gstreamer'а... то есть gst-launch-1.0. Либо потому что там нет нужного, либо потому что оно не задокументировано, либо потому что там адъ. Ему надо отдать должное за поддержку некоторых старых видеоформатов, за стриминг, но он не заменяет ffmpeg.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	92. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (-), 31-Янв-24, 03:56
	>> файлы битые > Битые файлы отдал ютуб, их скормили ffmpeg'у, он отказался их есть ("error > reading header") и ничего не поломал, т.к. он не меняет файлы in-place. Т.е. битые файлы выдал ютуб - а хомячок предъявил ффмпегу? О времена, о нравы! >> сломали поддержку вполне валидных mp4 > (не буду отвечать на все 10 твоих сообщений) Модераторы, может, грохнете того придурка Аноним(3) - он был агрессивен но технически оказался полностью некомпетентен. > Стандарт про этот Box говорит "Quantity: Exactly one". Прикольно вы того анона его же оружием то. Ширкаррррно. > То есть незаменимых конвейерами gstreamer'а... то есть gst-launch-1.0. Либо потому что > там нет нужного, либо потому что оно не задокументировано, либо потому > что там адъ. Конвееры gstreamer - это жесть и адъ на земле. Делано инопланетянами для инопланетян. Если кому ffmpeg казался творением ящерок, gstreamer иноплаенетянин среди инопланетян.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (3), 31-Янв-24, 09:35
	Ну фантазируешь, видно. Файлы не битые. 20 лет было нормально собирать dash в файл, а тут стало не нормально. Ну прекрасно, что сказать. Какие незаменимые инструменты ffmpeg ты сейчас назовёшь? Явно не кривые фильтры и никчёмные деинтерлейсеры. Программный скалер? Так тоже цветовые пространства вечно портил, искажает картинку с кучей гличей.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	107. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 11:01
	> Ну фантазируешь, видно. Файлы не битые. 20 лет было нормально собирать dash > в файл, а тут стало не нормально. Ну прекрасно, что сказать. Представляешь, чувак! В онлайн сервисе владелец сервиса может в любой момент что угодно поменять со своей стороны - и ты выкусишь огурца! Если ты не в курсе как эта штука с чанками сделана (MSE, Media Streaming Extension): JS кормит декодер браузера чанками. Где он их возьмет, как и в каком это формате будет - там вообще не регламентировано! То-есть предложен DASH, предложены некие форматы, но делать именно так - ничто имплементеров не обязывает. И если они скажем сделают самопальный формат чанков, а то и пошифруют их слегонца неочевидным ключом или там еще какая пакость - ну вот и думай что с этим блобом теперь делать, даже если ты его и ухватил. Полное решение - плеер вендора запустить. Он то знает как это до видика доделывать. Заодно и рекламу, вот, покажет. И если гугол решил приколоться и начал выгружать "немного нестандартный" формат - это вполне может быть и вот именно их инициатива. И даже - по именно нагибанию вон тех даунлоадеров. Они изредка по@бывают автоматические даунлоадеры. У vlc например так в какой-то момент отвалился ютуб - но если ему подпихнуть апдейченый lua-скрипт из найтли версии, где определение урлы поправили на новую версию плеера ютубы - все опять работает. > Какие незаменимые инструменты ffmpeg ты сейчас назовёшь? Явно не кривые фильтры и > никчёмные деинтерлейсеры. Это такой швейцарский нож с 120 лезвий что даже сложно все перечислить. 1) Продвинутого транскодирования. Он умеет выгружать всякие продвинутости как параметры кодеков для 264/AV1/etc как модное нынче "key-value api" современных кодеков. 2) Кривыми фильтрами я лично смог вытянуть несколько темных, шумных видео на которых изначально было не видно - нихрена. Но продвинутый пайплайн по мотивам "darktable" - сделал нечто достаточно смотрябельное. 3) Батч-транскодирование. В том числе с продвинутостями и/или в режиме fire and forget. Скажем я забацал себе скрипт который смотрит поворот камеры и кодирует сразу с поворотом - чтоб при декодировании проц не грузить этим постоянно. 4) Когда у знакомых хомяков сдох NTFS - и профукались все имена файлов (но их все равно вытащил photorec) - я вернул 600К файлов одупляемые имена по тегам камеры. Опять же пустил простой скриптик лукапать теги ffprobe'ом. Спасибо камерам за метаданные. Через 10 минут оно не только получило имена "как с камеры", но и по месяцам в диры было распихано, ибо 600К файлов в одной дире - не очень удобно. В линухе в принципе пашет, но в винде такая иерархия - не загрузится даже до послезавтра. Там уже при 100 000 - 150 000 файлов ждать задолбаешься. Но для этого - вот - ffprobe нужен был. 5) Им можно сделать даже что-то странное. Скажем анимированый gif/apng/webp из короткого клипа. Или мувик - из пачки картинок. Или деконструировать мувик в пачку картинок. > Программный скалер? Так тоже цветовые пространства вечно портил, > искажает картинку с кучей гличей. Сейчас бы с большинством матерьяла в LBD/YUV422 каком за цветовые пространства еще эстетствовать. Мсье, вы пижон. Кодируете небось сугубо 4:4:4/HDR/не менее 10 битов и 4К? И все это вот прям gstreamer'ом? А он так умеет вообще? У него ж все минимально продвинутые кодеки или отсутствуют или BAD. Ну вот такой фэйспалмовый фреймворк.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноньимъ (ok), 31-Янв-24, 02:27
	> I am running openSUSE Tumbleweed on snapshot dated 20231121. Опенсуса в репах тащит особую сборку ffmpeg из которой вырезано всё с "патентными проблемами". Проиграть простое mp4 видео - проблема. Ставишь кодек циски ииии видео идёт рывками, рассинхрон со звуком, краши. Онлайн радио с aac потоком - проиграть невозможно. Так что я не знаю какое отношение баг по ссылке имеет к ffmpeg вообще.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	91. Скрыто модератором	–3 +/–
	Сообщение от Аноним (-), 31-Янв-24, 03:52
	> Проиграть простое mp4 видео - проблема. > Ставишь кодек циски ииии видео идёт рывками, рассинхрон со звуком, краши. Или к вопросу за что патентованые форматы не лю в вебе. Но вы можете юзать росийские линухи, если конечно вам экспериенс уровня лады-калины заходит :)) > Так что я не знаю какое отношение баг по ссылке имеет к > ffmpeg вообще. Там похоже гугол стал грузить какие-то кривые файлы. Которые в браузере видимо играются. Гугль так то не оч лю даунлоадеры и иногда их по@бывает чтоб не наглели.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (3), 31-Янв-24, 10:17
	У меня самосборный ffmpeg, но это ровно тот же баг в ffmpeg. И по упоминаниям в обсуждении он же.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	108. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 11:49
	> У меня самосборный ffmpeg, но это ровно тот же баг в ffmpeg. > И по упоминаниям в обсуждении он же. Судя по обсуждению на гитхабе как я понимаю эту историю: 1) Отгружаемый гуглей в какой-то специфичной ситуации чанк - таки нарушает спеки стандарта. И это косяк не ffmpeg а именно гугли. А то что оно работало - результат laxed отношения к стандарту. Т.е. все строго наоборот относительно того что вы тут вопили. 2) ffmpeg запилил более строгое соответствие стандарту в какой-то момент - ибо fuzzer на это ругался. 3) После обнаружения что это ведет к траблам - ffmpeg сделали как вариант работы с строгим комплайнсом стандарту, так и laxed. А что еще они могут на своей стороне сделать? По моему - you're wrong on so many levels... а самый кривой в этой истории гугол, отгружающий нестандартный чанк, не? Хотя на специальный слом даунлоадеров не похоже, просто совпало забавно.
	Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+10 +/–
Сообщение от Аноним (16), 30-Янв-24, 15:31
Это теперь в новости попадают баги из нерелизных версий? Дожились.
Ответить | Правка | Наверх | Cообщить модератору

	30. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Bottle (?), 30-Янв-24, 16:10
	По факту, на уязвимость обратили внимание. Не обратили бы - её эксплуатировали бы по полной. Уж лучше уязвимость видеть в новостях опеннета, чем на практике.
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–2 +/–
	Сообщение от Аноним (31), 30-Янв-24, 16:14
	Так NSA нужно же как-то продвигать использование безопастных языков со строго контролируемым централизованным репозиторием.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	45. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+3 +/–
	Сообщение от Аноним (-), 30-Янв-24, 16:50
	О, новые теории заговора от поехавших! В безопастных языках, легко и непренужденно, разворачивается локальная репа. Зато типичных ошибок дырявых нету - на то язык и безопастный))
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (87), 31-Янв-24, 02:21
	>от поехавших Ну что ты так, среди r/rust попадаются и нормальные люди. Наверное. NSA Recommends Rust as (One) Memory Safe Alternative to C/C++ https://www.reddit.com/r/rust/comments/ysftwx/nsa_recommends.../
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (118), 01-Фев-24, 05:59
	А я думал вы о SWoDL
	Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
Сообщение от Аноним (-), 30-Янв-24, 15:36
О, зашибись! Открыл картинку и твой комп похачили... Fixes: out of array access - if (size <= head_size + 4) + if (size <= head_size + 4 || size > INT_MAX - ctx->skip) Классический out-of-bounds... Никогда не научатся *facepalm*
Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (22), 30-Янв-24, 15:48
	Не совсем, эту картинку надо открыть самим ффмпегом или софтом который его оборачивает. Может кто то и открывает картинки с VLC/mpv, но это не так чтобы гулял по интернетам а тут на тебе сюрприз.
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 30-Янв-24, 15:57
	Проблема что in general ты не знаешь кто юзает FFmpeg. Потому что его юзает куча софта(( Т.е. можно заморочиться и вывести все зависимости, но кто-то может тащить свою версию с собой... и вообще оно не стоит траты времени.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 00:32
	> Проблема что in general ты не знаешь кто юзает FFmpeg. Потому что > его юзает куча софта(( Но с практической точки зрения - сколько народа вот именно ffmpeg'ом что-то делало с jpeg XL? Этой фиче без году неделя, ее вообще врядли успели взять в оборот. Т.е. незачет, конечно, но реальный импакт... такое использование ffmpeg редкий кейс, а учитывая возраст фичи - спасибо если десяток человек на всю планету ЭТО уже делало. Теперь попробуйте их найти... > Т.е. можно заморочиться и вывести все зависимости, но кто-то может тащить свою > версию с собой... и вообще оно не стоит траты времени. Гугл заморочился и транскодирует мувики в отдельных "compute only" VM. Там IO с внещними миром нет и если даже хакнуть - то что вы упрете? Мувик который транскодировали? Так вы ж его и залили?! А больше там и брать нечего. Заметьте - так вообще все мыслимые вулны - в пролете. По любой причине.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (118), 01-Фев-24, 06:01
	Ну залей на разные видеохостинги или банки картинок, проверь.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	36. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Аноним (36), 30-Янв-24, 16:23
	Спорим ты бы никогда не нашёл и не пофиксил? А так то легко быть умным, когда за тебя уже все нашли и патч написали.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	96. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (96), 31-Янв-24, 08:12
	Но в Раст-то тоже можно переполнить инт и выполнить код за пределами... oh wait...
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	99. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним Ваноним (?), 31-Янв-24, 09:12
	Вообще не айти, но давно в лекции слышал, что на переполнения стоит трейт, где определяется поведение. А про выполнение не уверен, что возможно в safe коде
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (-), 31-Янв-24, 12:12
	> Вообще не айти, но давно в лекции слышал, что на переполнения стоит > трейт, где определяется поведение. А про выполнение не уверен, что возможно > в safe коде Сперва поинтересуйся как работает процессор. Потом - подумай захочешь ли ты платить ТУ цену в интенсивной математике. Да, это именно тот случай - если чекать флаги проца после всех математических операций, вся математика обвалится буквально в разы. В случае с кодеками это критично - они состоят из математики чуть менее чем полностью. А на скорость кодирования современными кодеками и так народ плюется кислотой.
	Ответить | Правка | Наверх | Cообщить модератору

27. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–2 +/–
Сообщение от Аноним (27), 30-Янв-24, 15:59
В Firefox уже завезли, найс, Mozilla не может без дыр, так ещё с Осла поведено и пороблено.
Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (3), 30-Янв-24, 16:23
	В firefox бандлится проблемная 6 версия ffmpeg кстати. Но, как показали авторы ffmpeg, нумерация не значит ничего и все ветки можно сломать одинаково и одновременно. Возникает вопрос, зачем им вообще несколько веток в таком случае?
	Ответить | Правка | Наверх | Cообщить модератору

29. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
Сообщение от Аноним (-), 30-Янв-24, 16:10
Ошибки прям типи-кал СИ. Тут и int overflow, и out of array access, и как вишенка на т̶о̶р̶т̶е̶  куче - code execution. Впрочем, ничего нового, ничего удивительного. Всё также, как и 30 лет назад))
Ответить | Правка | Наверх | Cообщить модератору

32. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
Сообщение от Аноним (31), 30-Янв-24, 16:16
Подскажите аналог на Rust.
Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (41), 30-Янв-24, 16:38
	Его нету
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–2 +/–
	Сообщение от Аноним (-), 30-Янв-24, 16:47
	Есть чистый раст github com/tirr-c/jxl-oxide Есть тоже чистый раст, но уже комбайн github com/etemesi254/zune-image, нужен zune-jpegxl Есть обертка либой docs rs/jpegxl-rs/latest/jpegxl_rs/ - на С++, но зато не дыряшка Достаточно?
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	58. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Другой Аноним (?), 30-Янв-24, 18:04
	> но зато не дыряшка докажи И вообще вопрос таков, более конкретно: подскажите аналог *ffmpeg* на Rust.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 00:33
	> Есть чистый раст github com/tirr-c/jxl-oxide > Есть тоже чистый раст, но уже комбайн github com/etemesi254/zune-image, нужен zune-jpegxl Это немного не аналог ffmpeg по возможностям и форматам. Ну так, мелочи какие.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	83. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (-), 31-Янв-24, 01:31
	Это реализация декодировщике формата JPEG XL. Которой достаточно для - внезапно - декодирования JPEG XL, вместо того, чтобы тащить всю зловонную кучу ffmpeg. С каких это пор либы-комбаный стали чем-то хорошим?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (87), 31-Янв-24, 02:17
	>тащить всю зловонную кучу ffmpeg Уровень безумия этого нефанатика заценили?
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 08:45
	> Это реализация декодировщике формата JPEG XL. > Которой достаточно для - внезапно - декодирования JPEG XL, вместо того, чтобы Чтобы что? Дописать остальную функциональность ffmpeg - это мягко говоря не моментально. Здоровенный проектец так то, с кучей фильтров и форматов. И всего лишь прочитать Jpeg XL не эквивалент фич ffmpeg. Он еще потом умеет дохреналион чего делать с этим. Ну вот например можно из пачки жыпегов - мувик собрать. А вы такое смогете накодить? А, ну да, при этом надо уметь жать в вон тот формат видео, mux'ить файло контейнера, аудиотрек наверное еще может захотеться. При том ffmpeg может выдать дофейхоа форматов, скажем, FLV древний. Или AV1 не очень древний. Или там H.264 какой. И еще более 9000 вариантов что и как. > тащить всю зловонную кучу ffmpeg. Ну так выпили его у себя из системы. И либы тоже не забудь, главное. Интересно же сколько и чего мультимедийного у тебя после этого вообще играться будет. > С каких это пор либы-комбаный стали чем-то хорошим? С таких, как никаких аналогов этого - не оказалось, а что либо минимально сравнимое - ну, это поставить в винды более 9000 разномастных кодеков. С понятным результатом. В остальных системах вы вообще врядли столько кодеков найдете, для виндов просто куча проприетарной байды изначально были...
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

33. Скрыто модератором	+/–
Сообщение от Аноним (33), 30-Янв-24, 16:17
Ну всё, допатчились...
Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
Сообщение от Аноним (3), 30-Янв-24, 16:19
Битые mp4 это вообще ни в какие ворота. Я откатился с 6 (баг появился в версиях новее 6.0.1) из-за лишних проблем с fps_mode и слишком долгого процессинга (раз в 50 дольше и жрёт процессор) на 5.1.3, нужна именно версия 5.1.3 и её ещё отдельно патчить, чтобы вообще скомпилировалось.
Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
Сообщение от Аноним (37), 30-Янв-24, 16:28
>Вторая уязвимость (CVE-2024-22862) возникла из-за целочисленного переполнения в функции jpegxl_anim_read_packet, используемой для декодирования анимации, и связана с использованием знакового типа int64_t вместо беззнакового uint64_t. Но чтобы буффер переполнить, нужна картинка на 8388608 тибибайт. Боюсь, что это больше, чем компьютер за всё свгё существование из пнета выкачивает. И больше, чем доступная оператива где-либо.
Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+1 +/–
	Сообщение от Аноним (3), 30-Янв-24, 16:38
	Sparse файл + ksm какой-нибудь, вполне осуществимо.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (49), 30-Янв-24, 17:04
	KSM - это известная дыра. См. dedup est machina.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 12:14
	> KSM - это известная дыра. См. dedup est machina. "Ну тогда и колеса тебе ни к чему" (c) анекдот про жигуль и мужика. В смысле, тогда и overcommit себе отключи. А то что программ меньше запускаться сможет на той же RAM - см выше про анекдот :). Без зарубания RCU и оверкомита, война с KSM - это даже не полумеры.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (117), 31-Янв-24, 21:36
	>В смысле, тогда и overcommit себе отключи Не могу - уже отключён ¯\_(ツ)_/¯.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 01-Фев-24, 09:13
	>>В смысле, тогда и overcommit себе отключи > Не могу - уже отключён ¯\_(ツ)_/¯. Так, круто. RCU наверное надо еще отпатчить нафиг, а то как же это - при форке нет полной копии процесса? KSM так, мелочь, на этом фоне то. Своп, конечно, тоже отключить. Ибо нефиг. Ща мы этому анону супер-безопасный комп сделаем! Я кстати говорил, что если от компа питание отцепить - то тогда хаксоры точно обломятся? Попробуй-ка оспорить не подцепленый шнур ремотно :)
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 00:37
	> Sparse файл + ksm какой-нибудь, вполне осуществимо. В полнолуние високосного года, если это четверг, и прошел дождичек, а на горе засвистел рак - можно найти фрика который зачем-то все же стал что-то делать с JXL через ffmpeg. И даже попробовать его хакнуть, если вдруг удастся как-то подсунуть ему sparse файл на дохреналион и у него не упадет система. ...а теперь коронный номер: попробуйте дожить до момента когда вы увидите это своими глазами.
	Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

	82. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (3), 31-Янв-24, 00:41
	При передаче по сети нули тоже сожмутся в ничто.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 04:07
	> При передаче по сети нули тоже сожмутся в ничто. Вот прям в ничто? Ух, где б такой кодек то взять? Я б взял парочку. А то даже если там сжатие будет довольно приличные 1000 к 1, от 8388608 тибибайт останется 8388.6 тибибайт что тоже так бы не очень весело качать.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (3), 31-Янв-24, 09:26
	Не хочешь качать, передай zip-bomb.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 12:17
	> Не хочешь качать, передай zip-bomb. Сейчас дофига кода если ratio выше разумного - просто сразу зарубает процессинг и можно обломаться за сам факт что это zip bomb. А так вообще угарный тредик вышел. На ffmpeg наехали за баг в нерелизнутой версии в новой (!!!) фиче, хотя так то - "оперативно словили, вот все б так!" скорее стоило сказать. Да еще предъявили ему за косяк ... гугли :). Все правильно сделали мля.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (3), 31-Янв-24, 12:26
	ТЫ не представляешь, как часто проверок оказывается недостаточно. А на ffmpeg наехали за баг в 5.1.4 (до сих пор единственная доступная версия для большинства, спустя несколько месяцев) и в 6.1 (вторая доступная версия в тестовой ветке). И только 6.0 "стабильная" версия с кучей проблем работает, при этом, 6.0.1 уже, по-моему, с багом (тоже "стабильная"). Ты просто ничего не понял. Ну и, видимо, модератор удалил соседний пост, в котором это объяснялось. Или ты пропустил. Или опять не понял, наиболее вероятно.
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 31-Янв-24, 16:50
	> ТЫ не представляешь, как часто проверок оказывается недостаточно. А на ffmpeg наехали > за баг в 5.1.4 (до сих пор единственная доступная версия для > большинства, спустя несколько месяцев) и в 6.1 (вторая доступная версия в > тестовой ветке). Спасибо, я почитал гитхаб. Там одно только DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE [x] I understand that I will be blocked if I intentionally remove or skip any mandatory* field ...достаточно гоорит об интеллектище тех кто ту штуку юзает. И кажется тут этот тренд был успешно продолжен :\. > И только 6.0 "стабильная" версия с кучей проблем работает, > при этом, 6.0.1 уже, по-моему, с багом (тоже "стабильная"). Ты просто > ничего не понял. В смысле? Там в баге на гитхабе написано что и где - с точностью до цуко комитов в ffmpeg. Что было на самом деле? - Fuzzer нашел баг когда ffmpeg делает что-то левое если ему дать файло с несколькими атомами ftyp. Это не по спекам, но ffmpeg это игнорил. И где-то ломалась логика. - Вылез Нидермейер, загасил баг fuzzer'а - сделав standard-compliant behavior, где только 1 ftyp можно, иначе отлуп что файл кривой. Потому что это не по спекам ISO. - Оказалось что гугол в каких-то специфичных ситуациях выгружал именно кривые файлы. Раньше их ffmpeg жрал из-за слабой валидации, но после вон того - перестал. Потому что файл реально кривой. - Нидермейер запилил фикс, что в зависимости от настройки либо вываливаться, либо продолжать. Х вам еще надо и зачем вы продолжаете демонстрировать подхайлайченый воооооон там уровень? > котором это объяснялось. Или ты пропустил. Или опять не понял, наиболее вероятно. Я таки прочитал всю историю бага и кажется более-менее понял что реально произошло. А вы таки конкретно стормозили.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (3), 31-Янв-24, 17:10
	Теперь тебе пользователи умом не вышли, красавчик. Это всё не имеет значение, сабжем пользуются самые обычные люди и это одна из наиболее популярных опенсорс-поделок в мире. >где-то ломалась логика Нигде ничего не ломалось, зачем ты опять выдумываешь? Он просто спамил в лог. 20 лет всё всех устраивало, но тут понадобилось гениально закрутить гайки в минорном обновлении. Основная мульимедиа-либа всего опенсорса, я напоминаю. И в итоге оставили как есть уже несколько месяцев. Правильно, нужно чтобы всем дошло, зачем все проекты бандлят собственный протухший форк ffmpeg.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 01-Фев-24, 10:56
	> Теперь тебе пользователи умом не вышли, красавчик. Что вижу - то и пою. Вроде единственный проект где я ТАКУЮ плашку видел. Явно не от хорошей жизни вкатили. > Это всё не имеет значение, сабжем пользуются самые обычные люди Для обычных - ffmpeg, имхо, сложноват. Им байду с 3 кнопками в андроиде, с рекламой и спайварью. Большего такой подход к делу не заслуживает. > и это одна из наиболее популярных опенсорс-поделок в мире. Тем не менее, 1) Ее разработчики никого не заставляли ей пользоваться и никому ничего не должны. 2) Воон там сорц. Не нравится патч нидермейера? Откатите. Выкатите патч лучше. Можете даже апстриму прислать. Врядли будут ногами отбиваться, если проблему обрисовать. Цивилизовано, без таких воплей. А с такими воплями - от вас такую же плашку повесят, это отфильтрует агрессивных тупарей. > Нигде ничего не ломалось, зачем ты опять выдумываешь? Он просто спамил в > лог. 20 лет всё всех устраивало, но тут понадобилось гениально закрутить > гайки в минорном обновлении. Fuzzer (по иронии тоже на мощностях гугли работает) репортнул пробему. Ее пофиксили. А 20 лет назад бота не было. И fuzzer - рандомно генерит. Как нагенерил что-то проблемное так и чинят. Тест методом миллиона обезьян и печатных машинок. Только автоматический. > Основная мульимедиа-либа всего опенсорса, я напоминаю. И > в итоге оставили как есть уже несколько месяцев. Правильно, нужно чтобы > всем дошло, зачем все проекты бандлят собственный протухший форк ffmpeg. Видимо прийти к девам и обрисовать проблему, а то и прислать патч никто толи не допер, толи проще было вон то (ORLY?). Разработчкики ffmpeg конечно бывают странноватые, но врядли у них есть самоцель что-то сломать в своем проекте.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Аноним (-), 30-Янв-24, 16:44
	Не обязательно. Может там есть еще одна узявимость, которая позволяет хакнуть размер. А может все проще (если читать статю)) и достаточно "специально оформленных изображений". Просто созддаешь картинку которая думает что она 100500 тибибиайт в квадрате и все. Помнишь раньше было такое развлечение zip-бомбы?
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	46. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 30-Янв-24, 16:53
	"Не смей его критиковать! Да он делает овно, но зато какое! И мы будем противиться внедрению инструментов не позволяющих делать овно!!!" Как-будто речь об умственно отсталых, нельзя коворить что они делают плохо, они ведь так стараются! Хотя... речь же о сишниках? А тогда все норм.
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	48. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+2 +/–
	Сообщение от Аноним (41), 30-Янв-24, 17:02
	"Не смей его критиковать! Да он делает овно, но зато какое! И мы будем противиться внедрению инструментов не позволяющих делать овно!!!" Как-будто речь об умственно отсталых, нельзя коворить что они делают плохо, они ведь так стараются! Хотя... речь же о сишниках? А тогда все норм. Я не понимаю, вас сишники силой заставляют юзать их софт чтоли? Ну напиши на расте (или правильнее сказать перепиши) и будет все в безопасносте. Зачем вы, болезные, мучаетесь и страдаете?
	Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

	51. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (51), 30-Янв-24, 17:16
	тогда не будет повода поныть на форуме и придётся работать
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–1 +/–
	Сообщение от Аноним (57), 30-Янв-24, 18:04
	Внимание! Все видите? Вот вам живой пример, как растоманы заставляют юзать их софт.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	88. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (87), 31-Янв-24, 02:27
	Несуществующий? Вот садисты.
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (118), 01-Фев-24, 06:11
	А почему не на go или zig?
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

100. "Уязвимости в реализации JPEG XL из состава FFmpeg"	–2 +/–
Сообщение от Данные в так называемом поле Name (?), 31-Янв-24, 09:24
Правильно ли я понял ситуацию? Гипотетически могло произойти следующее: сегодня ты конвертишь прон, а завтра дом твой заложОн?
Ответить | Правка | Наверх | Cообщить модератору

	125. "Уязвимости в реализации JPEG XL из состава FFmpeg"	+/–
	Сообщение от Аноним (-), 01-Фев-24, 11:00
	> Правильно ли я понял ситуацию? Гипотетически могло произойти следующее: сегодня ты конвертишь > прон, а завтра дом твой заложОн? Гипотетически много чего может произойти. Например все молекулы воздуха выйдут из вашей комнаты и соберутся в соседней. Но вероятность этого события такова что вы до этого не доживете.
	Ответить | Правка | Наверх | Cообщить модератору

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

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