Компания Secunia Research выступила (http://secunia.com/blog/372/) с критикой методов реагирования проекта VideoLAN на обнаружение уязвимостей в медиапроигрывателе VLC, приведя пример двух уязвимостей, позволяющих организовать выполнение кода при обработке файлов в форматах SWF и MKV. Первая уязвимость (http://secunia.com/advisories/51464/) была выявлена в декабре прошлого года, а вторая (http://secunia.com/advisories/52956/) в апреля нынешнего года. Исправление первой проблемы было заявлено ещё в выпуске 2.0.5, но на деле уязвимость остаётся неисправленной до сих пор, в том числе и в последней версии 2.0.7. Похожая ситуация наблюдается и со второй уязвимостью, исправления которой не вошли в состав VLC 2.0.7. По заявлению Secunia Research компания уже несколько месяцев не может добиться исправления уязвимостей и поэтому вынуждена придать ситуацию огласке.
В ответ на критику разработчики VLC опубликовали (http://www.jbkempf.com/blog/post/2013/More-lies-from-Secunia) достаточно резкое сообщение, в котором обвинили Secunia во лжи и предвзятости. По поводу первой уязвимости утверждается, что VLC никогда официально не поддерживал формат SWF, уязвимость находится в коде библиотеки из состава FFmpeg/libav и исправление было включено в сборки VLC 2.0.5. Secunia указывает на то, что было устранено лишь частное проявление проблемы, но уязвимость по сути осталась неисправленной. Что касается проблем в сторонних библиотеках, то сборки VLC поставляются статически связанными с уязвимой версией libav, что делает весь продукт уязвимым, независимо от того в чём коде имеется ошибка.
Вторая уязвимость заявлена разработчиками VLC как неэксплуатируемая и приводящая только к краху приложения, поэтому они не считают проблему уязвимостью. В ответ на данное заявление, в списке рассылки FullDisclosure независимым исследователем безопасности был опубликован (http://seclists.org/fulldisclosure/2013/Jul/71) рабочий прототип эксплоита (ранее эксплоит не был доступен публично), показывающий, что проблема представляет реальную угрозу для пользователей. В примечании указывается, что Secunia Research профессионально занимается проблемами безопасности, поэтому стоит прислушаться к их мнению о степени опасности проблемы, а не придумывать оправдания о незначительности выявленной ошибки.URL: http://secunia.com/blog/372/
Новость: http://www.opennet.me/opennews/art.shtml?num=37389
Зря они так. Звезду, что ли, поймали?
А теперь они поймали звиздюли от секурити-исследователей, которые не любят раздолбаев :)
пользователь выбирает vlc, а не безопасность, и это нормально.
то есть я лично не знаю, насколько специалисты из secunia компетентны (и оценить не могу), но если их мнение не сходится с мнением автора программы (причем именно оценочное мнение), то они скорее всего ошибаются.
> пользователь выбирает vlc, а не безопасность, и это нормально.только для безмозглых даунов.
с чего это вдруг?
я им музыку слушаю, софт с задачей справляется. в общем-то я еще рядом плееров для того же пользуюсь (по ситуации). каких-то иллюзий насчет безопасности софта я в целом не питаю.
а вот пользоваться программой, и не доверять мнению её автора о её же безопасности (не будучи специалистом) - это как раз ближе к клиническим случаям.
> с чего это вдруг?не «vlc для безмозглых даунов», а «только безмозглые дауны плюют на безопасноть». безотносительно названия программы.
> доверять мнению её автора о её же безопасности (не будучи специалистом) - это как раз ближе к клиническим случаям.
> а вот пользоваться программой, и не доверять мнению её автора о её
> же безопасности (не будучи специалистом) - это как раз ближе к
> клиническим случаям.В том и дело, что secunia - сайт _специалистов_ по безопасности.
Скачал я их файлик mkv, попробовал его просмотреть, KPlayer пишет "ошибка". Другие программы ничего не пишут, но и ничего не показывают. Никакого Access violation нетути, как ни старайся (старался не очень сильно). Да, забыл сказать, у меня-же GNU/Linux.
А чо такую мякотку то опустили?> Later, another researcher independently contacted us via SVCRP (Secunia Vulnerability Coordination Reward Program) and reported a vulnerability in VLC version 2.0.5. When we analysed the vulnerability, it turned out to be the same use-after-free issue described in SA51464 - only the vector this time was via an AVI file rather than an SWF file.
А тем временем в FFMPEG тихо и без возгласов появилась поддержка OpenCL
>А тем временем в FFMPEG тихо и без возгласов появилась поддержка OpenCLНасколько я знаю - только экспериментально в фильтрах.
Лично мне функциональность фильтров - до лампочки...
> Насколько я знаю - только экспериментально в фильтрах.Первая ласточка. А тем временемм в амдшных открытых драйверах opencl тоже понемногу допиливается. Через несколько годков все это соберется в милейшую такую конструкцию, мощную и современную :)
Шо, неужто VLC тоже школьники разрабатывают?
А что по нему не видно?
> А что по нему не видно?Первая ветка еще ничего была.
А вот со второй все стало понятно.
Конечно VLC пишут школьники и аналитики.
Настоящие же созидатели на опёнке в камментах творят шедевры!
Оборванцы и там и там. Голодные злые оборванцы.
Ладно хоть в микрософте и АНБ сытые, добрые и порядочные люди работают.
Ты видел как они ssa/ass субтитры с эффектами рисуют на видео, непропорциональном экрану? Да даже если оно пропорционально он их корёжит. Да и корректно конвертировать цвета они научились лишь недавно. -_-
Не знаю кто они, но хорошими словами назвать как-то осложнительно.
> Шо, неужто VLC тоже школьники разрабатывают?студенты. которые немногим лучше.
Ты так говоришь, как будто 95% обладателей дипломов кодят лучше скубентов.
Если человек дурак - это на всю жизнь.
> Ты так говоришь, как будто 95% обладателей дипломов кодят лучше скубентов.нет, я так не говорю. именно поэтому после «студенты» я добавил характеристику.
> которые немногим лучшеПрекрасная характеристика. Что интересно, выделение голосом конкретного слова меняет смысл на противоположный.
> Вторая уязвимость заявлена разработчиками VLC как неэксплуатируемая и приводящая только к краху приложения, поэтому они не считают проблему уязвимостьювсё ясно в вами ребята.
вашего плеера не будет у меня на компьютере. (хотя ведь и не было).
от горэ...
Раньше юзал VLC, годный плеер, универсальный: от айпирадио до твтюнера.Мущай мужики покипят - нужно иногда кровь разгонять чтобы двигаться, ничего страшного в этом споре нет. Побухтят и сделают как надо, не ссыте.
> был опубликован (http://seclists.org/fulldisclosure/2013/Jul/71) рабочий прототип
> эксплоита (ранее эксплоит не был доступен публично), показывающий, что проблема представляет
> реальную угрозу для пользователей.а какую именно представляет угрозу для пользователей файл, который крэшит приложение?
хотелось бы понять, как именно это можно использовать.
> а какую именно представляет угрозу для пользователей файл, который крэшит приложение?Крэшит приложение он за счет того, что перезаписывает область памяти, в которой хранится ее исполняемый код. Если записать туда рандомные байты, или просто выйти за границы области - программа рухнет. А вот если зафигачить туда зловредный код - все становится интереснее...
>> а какую именно представляет угрозу для пользователей файл, который крэшит приложение?
> Крэшит приложение он за счет того, что перезаписывает область памяти, в которой
> хранится ее исполняемый код. Если записать туда рандомные байты, или просто
> выйти за границы области - программа рухнет. А вот если зафигачить
> туда зловредный код - все становится интереснее...Перезаписывает ли? Вы бэктрейс видели?
> Перезаписывает ли?Да.
> а какую именно представляет угрозу для пользователей файл, который крэшит приложение?Там где крэш, там зачастую и выполнение кода, если повезет. Зависит от того что именно программа при этом делает, конечно, и насколько там в системе все обложено stack-protector, fortify source и прочими ASLR. Однако в целом потенциал имеется и недооценивать крахи - глупо. Для разработчиков лучше всего считать что если программа падает - это критичная проблема и чинить ее ASAP. Это наиболее безопасный и ответственный вариант.
вообще-то любой баг лучше починить. подход «ну да, падает. и что? баг некритичный, нам лень его чинить. и вообще, это не наш баг, это чужой баг!» — весьма… странный, если мягко выражаться.впрочем, это же vlc. родился как корявая студподелка и развивается так же.
> вообще-то любой баг лучше починить. подход «ну да, падает. и что? баг
> некритичный, нам лень его чинить. и вообще, это не наш баг,
> это чужой баг!» — весьма… странный, если мягко выражаться.Так ведь его и починили, вот только secunia достаточно, ээ, туповаты, чтобы это увидеть.
> Так ведь его и починили, вот только secunia достаточно, ээ, туповаты, чтобы
> это увидеть.я, в данном случае, после поверхностного чтения не понял, кто на ком сидел. автор говорит одно, секуния другое — надо самому шариться по исходникам. а лень.
>> а какую именно представляет угрозу для пользователей файл, который крэшит приложение?
> Там где крэш, там зачастую и выполнение кода, если повезет. Зависит от
> того что именно программа при этом делает, конечно, и насколько там
> в системе все обложено stack-protector, fortify source и прочими ASLR. Однако
> в целом потенциал имеется и недооценивать крахи - глупо. Для разработчиков
> лучше всего считать что если программа падает - это критичная проблема
> и чинить ее ASAP. Это наиболее безопасный и ответственный вариант.это локальное выполнение кода. с правами пользователя, который открывает файл.
причем среди поддерживаемых форматов часть это позволяет в штатном режиме.падать конечно не надо, бага есть бага. но это просто бага, их искать даже не надо - файлов, от которых проигрыватели коры дампят - навалом, и без происков хакеров )
> это локальное выполнение кода. с правами пользователя, который открывает файл.как будто этого мало.
> причем среди поддерживаемых форматов часть это позволяет в штатном режиме.
э? кто это там позволяет выполнять произвольный код? O_O
> файлов, от которых проигрыватели коры дампят
> — навалом, и без происков хакеров )можно мне хотя бы десяток? чтобы mplayer2 упал. чёрт, это же офигенно: навалом файлов, которые крашат плеер, и никто баги не чинит! да я же прославлюсь, понаприсылав сотни патчей!
> как будто этого мало.это не мало или много, это просто достаточно для извлечения выгоды (т. е. для массовой эксплуатации).
> э? кто это там позволяет выполнять произвольный код? O_O
я не знаю деталей их виндовой кухни, но как-то с asf умудряются вообще кодеки из сети качать, во флеше скрипты поддерживаются, да даже в dvd в меню какую-то логику закладывают (не уверен насчет тьюринг-полноты, но похоже есть). это для локальных файлов разве ограничивают специально?
> можно мне хотя бы десяток? чтобы mplayer2 упал. чёрт, это же офигенно: навалом файлов, которые крашат плеер, и никто баги не чинит! да я же прославлюсь, понаприсылав сотни патчей!
давайте попробуем, только в розницу - по одному файлику, я ж их не копил и не сохранял специально. :) и условия задачи как-то конкретизировать, чтобы эти баги у вас воспроизводились. покажите ldd `which mplayer2` список и mplayer2 -v верхушку, где состав и номера версий. ну и какие-то еще если есть ограничения (какие случаи не интересны, или наоборот) - тоже не помешает знать. получится - всем будет хорошо - вы прославитесь, а я хоть в полезном деле поучаствую.
> я не знаю деталей их виндовой кухни, но как-то с asf умудряются
> вообще кодеки из сети качать, во флеше скрипты поддерживаются, да даже
> в dvd в меню какую-то логику закладывают (не уверен насчет тьюринг-полноты,
> но похоже есть). это для локальных файлов разве ограничивают специально?это, всё-таки, не произвольный код с доступом к произвольному API.
>> можно мне хотя бы десяток? чтобы mplayer2 упал. чёрт, это же офигенно: навалом файлов, которые крашат плеер, и никто баги не чинит! да я же прославлюсь, понаприсылав сотни патчей!
> давайте попробуем, только в розницу — по одному файлику, я ж их
> не копил и не сохранял специально. :) и условия задачи как-то
> конкретизировать, чтобы эти баги у вас воспроизводились. покажите ldd `which mplayer2`
> список и mplayer2 -v верхушку, где состав и номера версий.можно смело рассчитывать на то, что mplayer2 раз в пару недель пересобирается из git. соответственно, версия «самый новый». кстати, и пересоберу сейчас, раз уж всё равно суд да дело.
ldd точно нужен? оно жЫрное, и в основном состоит из бесполезных libXXX.so.[012] да кучи иксовых библиотек.
> и какие-то еще если есть ограничения (какие случаи не интересны, или
> наоборот)в принципе, не особо интересны случаи, когда баги в библиотеках, не идущих с mplayer2, но я понимаю, что это без анализа не определишь. а, и архитектура у меня x86, так что краши для x86_64, которые нельзя повторить на x86 — тоже мимо.
опять же, можно в жабир стукнуть: arisu@neko.im
"файлов, от которых проигрыватели коры дампят - навалом"mplayer у меня за Х лет ни разу не падал в кору. Навалы в студию.
> "файлов, от которых проигрыватели коры дампят - навалом"
> mplayer у меня за Х лет ни разу не падал в кору.
> Навалы в студию.дык зачем они вам? убедиться что у вас он тоже не бессмертный?
так это я не буду спорить, я наоборот подтвердить могу - да, при правильном использовании он хорошо работает, если за Х лет он у вас стабильно работал - то в ближайшие Х*Y хуже работать не станет, только лучше.
а падает он во-первых не из-за собственных багов, во-вторых баги, против которых существует и давно известен workaround - мало кому интересны.
> mplayer у меня за Х лет ни разу не падал в кору.Не аргумент. Может вы им 2 файла за X лет проигрывали? :)
Реально же почти любой плеер на тех или иных файлах может начать испытывать проблемы. Форматы сложные, навороченные. Вполне бывает что оказывается что парсер - лох. И совсем не ожидал что вон в то поле формата запишут нечто этакое, нестандартное. И не всегда это корректно ловится обработчиками ошибок. Если этого не случилось - что последует дальше весьма зависит от.
> это локальное выполнение кода. с правами пользователя, который открывает файл.Вы так говорите, как будто потеря пользовательских данных менее страшна, чем системных.
Про остальные Ваши перлы анонимусы выше уже все Вам рассказали, я вижу.
Раз они такие спецы в этой секунии, взяли бы и пофиксили, это же опенсорс, нет, они предпочитают вопить и самопиариться
Это их бизнес. Авось кто-то закажет у них исследование безопасности.
> Это их бизнес. Авось кто-то закажет у них исследование безопасности.Дык заказывают, и очень многие.
Помоему пиар "Мы нашли ошибку и исправили" много лучше, чем "мы нашли ошибку и орем"
> Помоему пиар "Мы нашли ошибку и исправили" много лучше, чем "мы нашли ошибку и орем"Орут они потому, что разработчики VLC не заинтересованы в исправлении ошибок.
>> Помоему пиар "Мы нашли ошибку и исправили" много лучше, чем "мы нашли ошибку и орем"
> Орут они потому, что разработчики VLC не заинтересованы в исправлении ошибок.Это не правда.
> Раз они такие спецы в этой секунии, взяли бы и пофиксили, это же опенсорсКак бы они пофиксили? Форкнули VLC?
>Как бы они пофиксили? Форкнули VLC?man patch
В апстриме VLC в таких патчах не заинтересованы.
> В апстриме VLC в таких патчах не заинтересованы.Да ну... "Лень править" и "принципиально не принимаем" - разные вещи.
> Да ну... "Лень править" и "принципиально не принимаем" - разные вещи.Обычно принять сложнее, чем поправить самому.
Почему?
> Почему?В обоих случаях нужно понять проблему и способ её решения, но в случае чужого кода нужно ещё и разобраться в чужом коде и понять как именно он работает, и не содержит ли своих косяков. Иногда это довольно нетривиально.
А вы уверены, что тот человек, которы писал проблемыый код, щас вообще уделяет какое-то внимание VLC? Если вы строчку кода добавите в проект, вы уже разработчик. К томуже они в этой секунии явно разобрались в коде, если нашли ошибку.
> А вы уверены, что тот человек, которы писал проблемыый код, щас
> вообще уделяет какое-то внимание VLC? Если вы строчку кода добавите в
> проект, вы уже разработчик. К томуже они в этой секунии явно
> разобрались в коде, если нашли ошибку.Чей код был сначала не суть важно. Когда сам исправляешь сам же и понимаешь что ты наделал. А тут же ещё нужно понять что кто-то за тебя наделал и согласен ли ты с этим решением.
Ну а для поиска ошибки вовсе не обязательно разбираться в коде. Достаточно уметь фаззить входные данные. Рано или поздно ошибка обязательно вылезет, если таковая есть. Для использования же найденной ошибки тоже в код смотреть не обязательно. Гораздо важнее знать как этот код собирался и какие защиты придётся обходить, чтоб в процессе краха вкорячить свой бинарник в исполнимую область и передать на него управление. Собственно это ведь делают и с закрытым софтом вовсе не имея на руках исходников.
> Чей код был сначала не суть важно. Когда сам исправляешь сам же
> и понимаешь что ты наделал. А тут же ещё нужно понять
> что кто-то за тебя наделал и согласен ли ты с этим
> решением.Ну ей богу! принятие патча этож не единовременная процедура. Если код непонятен - можно задать вопрос. Если исправляющему ошибку непонятно что-то в коде - он может задать вопрос. Если вам прислали патч, который не только исправляет ошибку, но и вносит новую - можно пропросить его исправить патч, объяснив что не так.
Всё это хорошо и удобно при добавлении новой функциональности в приложение или обновлении старой, которую сам не хочешь трогать и трёхметровой палкой или просто времени на неё нет. Посмотрел, что там за тебя натворили, понравилось - принял, не понравилось - отправил на доработку. Вот только проблемы безопасности не те проблемы, которые стоит спихивать на третьих лиц и с которыми можно играть в пинг-понг месяцами. Их должен решать тот, кто лучше всех понимает код, в котором проблема содержится, и это определённо не ребята из Секунии, которые, возможно, на сорцы VLC даже и не смотрели ни разу. Тем более, что в случае тривиальных проблем вроде переполнения буфера проблема решается самым минимумом правок. Патчь будет сложнее принять просто потому, что самому написать их в нужном месте будет быстрее, чем проверять, написали ли проверки в нужном месте за тебя. В конце-концов в проблему вникать так и так придётся. -_-Тут даже не столько вопрос «Сложнее ли принять чужой код, чем исправить самому?», который мы сейчас обсуждаем, сколько «А оно им надо — исправлять чужой кривой код, когда рекламу им создают успешные взломы и деньги платят практически за это же?»
Разве к прилагающемуся патчу, обычно не добавляют описание того, в чем заключается проблема и как патч ее решает? По-моему вы рассматриваете наихудший результат, поэтому уже изначально настроены отклонить код, просто потому что он чужой.К тому же "оценку" патчу обычно дают сразу несколько разработчиков, а не один самый умный.
Мне так наоборот кажется, что даже если вам прислали "плохой" патч (плохо оформленный код, с корявым исправлением), то даже написать свое исправление на базе уже известного, но плохого патча намного проще и быстрее.
это только кажется. а на деле — всё равно надо разобраться, откуда именно возникает баг. потому что присланый патч может проблему, например, вовсе не решать, а только маскировать, и она потом вылезет в другом месте. а может решать, рождая другие баги, потому что автор патча не в курсе остальных частей кода. и ты пы.а review делает тот, к чьей подсистеме патч относится. ну, или несколько «тех». именно потому, что оценивается не только и не столько «гениальность патча», а то, насколько патч ничего не ломает.
> Почему?Потому что прочитать и _понять_ чужой код обычно сложнее, чем придумать и написать свой. Первая из этих задач - обратная, вторая - прямая.
Не говоря уже о том, что нужно править стилистику (если не хочется, чтобы код проекта напоминал жертву мутаций).
> Не говоря уже о том, что нужно править стилистику (если не хочется,
> чтобы код проекта напоминал жертву мутаций).Большинство нормальных программистов, присылающих вам исправления, будут придерживаться того же стиля оформления кода что и в остальном коде проекта. Будьте оптимистами в конце концов! :)
>>Как бы они пофиксили? Форкнули VLC?
> man patchВопрос был о процедуре исправления, а не о процедуре выделения разницы (man diff) и наложения результата получателем (вот тут man patch, если не сразу man git-am).
> Раз они такие спецы в этой секунии, взяли бы и пофиксили, это
> же опенсорс, нет, они предпочитают вопить и самопиаритьсяЗнаешь, для начала нужно найти на какой участок кода мапится бинарный код, который допускает лажу. Потом изучить чужой код, потом исправить, потом пропихнуть в апстрим… нереальная куча лишней головной боли. Найти хитрый способ скрашить чужое приложение само по-себе достаточно сложно, чтоб ещё и исправлять потом чужие косяки. Они просто тычут всех носом в их собственные фекалии и заставляют убирать за собой. Очень правильный подход, я считаю.
>> Раз они такие спецы в этой секунии, взяли бы и пофиксили, это
>> же опенсорс, нет, они предпочитают вопить и самопиариться
> Знаешь, для начала нужно найти на какой участок кода мапится бинарный код,
> который допускает лажу. Потом изучить чужой код, потом исправить, потом пропихнуть
> в апстрим… нереальная куча лишней головной боли. Найти хитрый способ скрашить
> чужое приложение само по-себе достаточно сложно, чтоб ещё и исправлять потом
> чужие косяки. Они просто тычут всех носом в их собственные фекалии
> и заставляют убирать за собой. Очень правильный подход, я считаю.это не та сфера, где приложение сложно скрашить :)
там одних либ линкуется столько (и из таких источников), что бинарь запустить уже радость, не то что файл открыть.
> это не та сфера, где приложение сложно скрашить :)
> там одних либ линкуется столько (и из таких источников), что бинарь запустить
> уже радость, не то что файл открыть.Скрашить в принципе может любой дурак с некоторым опытом фаззинга. Было бы желание и время. А вот суметь использовать найденный баг уже проблема. Причём иногда крайне нетривиальная проблема.
Они же и это сделали.
вот если бы они нашли способ поиметь пользователя без его участия - было бы интересно. а это нужно либо удаленное что-то (а vlc без специальных действий не начнет сеть слушать), либо плагин в браузере, либо софт должен быть сверхмассовый (как винда).никто же не отрицает факт наличия ошибки в коде. однако опасность пока что - потенциальная, а затраты сил и времени предлагается понести вполне себе реальные. причем денег вроде как secunia авторам не предлагали, либо по цене не сошлись, либо вообще все было затеяно ради инфоповода (а сейчас уже внимание публики привлечено и show must go on).
Вообще-то если ты не забыл эксплоит найден в коде обработки видео-контейнера. Фактически тут нужен самый минимум действий со стороны пользователя.
Как поиметь пользователя? Причём много сразу? Да элементарно. VLC до сих пор довольно популярный плеер и не стоит сбрасывать его со счетов. Берём какую-нибудь новинку кино, модифицируем контейнер соответствующим образом засунув туда эксплоит и нужный нам код, и выкладываем это счастье на все трекеры страны. Пользователи других плееров возможно даже не заметят подставы — у них плеер только лишь тихо выматерится и проскипает «битое» место выдав немного артефактов на экране, а может и вовсе замолчит, а вот все пользователи VLC получат подарочек. При правильном подходе можно даже заглушить ошибку и восстановить воспроизведение, чтоб они вообще не заметили, что их поимели. Одного раза мало? Берём ещё какую-нибудь новинку голливудских испражнений и так пока не надоест.Одну только версию 2.0.5 под винду скачали ~45 000 000 раз. Если предположить, что нам достанется 5-10% из них, то это уже весьма недурственный ботнет, а если учесть, как пользователи винды из кожи вон лезут обновляться, то пользователей у VLC может быть даже в несколько раз больше, а уязвимые версии будут ещё использовать и использовать. Особенно если никто достаточно долго не будет замечать происходящего и удастся тихо заразить как можно больше машин.
> вот если бы они нашли способ поиметь пользователя без его участия -Ну как бы открыл мувик - тыдыщ! Поимели. Участие, конечно, требуется, но - минимальное. А чего такого криминального в том чтобы открыть мувик? Никто не ожидает в этот момент какой-либо подставы :)
> заявлена разработчиками VLC как неэксплуатируемая и приводящая только к краху приложения, поэтому они не считают проблему уязвимостьюПрямо как разработчики Debian. Подумаешь, локальный рут.
Бредишь?
> сути осталась неисправленной. Что касается проблем в сторонних библиотеках, то сборки
> VLC поставляются статически связанными с уязвимой версией libav, что делает весь
> продукт уязвимым, независимо от того в чём коде имеется ошибка.То есть подвержена только бинарная сборка с офсайта? В дистрибутивах своя линковка.
> То есть подвержена только бинарная сборка с офсайта? В дистрибутивах своя линковка.А ты думаешь, что все эти страсти - вокруг линуксовой версии?
> VLC 2.0.7В openSUSE нет такой версии, интересно чего бы это значило. Серверам из top500 VLC не нужен?
>> VLC 2.0.7
> В openSUSE нет такой версии, интересно чего бы это значило. Серверам из
> top500 VLC не нужен?да просто нумерация не соответствует апстриму, бывает
Напоминает анекдот про хакера и солонку.
> Напоминает анекдот про хакера и солонку.Который из?
> Напоминает анекдот про хакера и солонку.Проблема только в том что качнули вы где-то "замечательный клип" а оказывается хакер у вас уже все солонки то и упер как раз :).
Печально. Вместо того, что-бы отмазки придумывать, лучше бы разработчики VLC пофиксили данные уязвимости.
> Печально. Вместо того, что-бы отмазки придумывать, лучше бы разработчики VLC пофиксили
> данные уязвимости.эти т.н. "уязвимости" исправлены, не стоит верить т.н. "секьюрити фирмам" типа secunia.
> эти т.н. "уязвимости" исправлены, не стоит верить т.н. "секьюрити фирмам" типа secunia.Вообще-то secunia достаточно неплохо в своем ремесле шарит и за годы работы они зарекомендовали себя вполне заслуживающим внимания ресурсом где публикуются вполне себе уязвимости.
> Вообще-то secunia достаточно неплохо в своем ремесле шарит и за годы работы они зарекомендовали себя вполне заслуживающим внимания ресурсом где публикуются вполне себе уязвимости.Есть и другия мнения на этот счет.
>> Вообще-то secunia достаточно неплохо в своем ремесле шарит
> Есть и другия мнения на этот счет.Костик, лучше всё-таки избегать чрезмерных обобщений -- насколько понимаю (хотя это крайне поверхностно, скорее всего), в данном разе могло получиться так, что они недостаточно разборчиво вписались за недостаточно грамотного исследователя.
Надеюсь, ситуация будет сколь-нибудь обстоятельно разобрана и участники сделают выводы.
DISCLAIMER: в представленные доказательства не вникал, не моя предметная область.
>>> Вообще-то secunia достаточно неплохо в своем ремесле шарит
>> Есть и другия мнения на этот счет.
> Костик, лучше всё-таки избегать чрезмерных обобщений -- насколько понимаю (хотя это крайне
> поверхностно, скорее всего), в данном разе могло получиться так, что они
> недостаточно разборчиво вписались за недостаточно грамотного исследователя.
> Надеюсь, ситуация будет сколь-нибудь обстоятельно разобрана и участники сделают выводы.Secunia последовательно в течение нескольких месяцев подтверждает свою некомпетентность, лично для меня выводы очевидны...
Да, все могло быть гораздо лучше, если бы они шли навстречу и делали то, что обещали (например, высылать PoC и эксплоиты), а не врали.
С другими security-компаниями у нас проблем нет.
Да, судя по блогу Жана Батиста, Секуниа еще и задним числом меняла свои advisories.
> Есть и другия мнения на этот счет.Мнения фанатов vlc не в счет.
>> Есть и другия мнения на этот счет.
> Мнения фанатов vlc не в счет.Фанатам ляпнуть-что-нибудь: thresh@ -- один из разработчиков VLC.
Ну так и описал бы внятно ситуацию
> thresh@ — один из разработчиков VLC.зачем дискутировать с теми, кто этого не понял?
vlc я в своей жизнм видел только у виндусоидов. На божественном жму/линуксе пользователи могут использовать удобнейший mplayer. Так что проблема не коснется нормальных пользователей.
> vlc я в своей жизнм видел только у виндусоидов. На божественном
> жму/линуксе пользователи могут использовать удобнейший mplayer. Так что проблема не коснется
> нормальных пользователей.Удобнейший mplayer также замечательно работает на Виндоусе. Вместе с vlc они наверное самые лучшие и неприхотливые плееры на Венде.
Теперь вне Виндоуса: mplayer vs. vlc, оба они почти одинаково замечательны. По ресурсам mplayer чуть-чуть на пару % может быть более эффективней. vlc однако имеет родные front-end на любой вкус и цвет с массой возможности для регулировки on the fly, напр. aspect ratio. vlc напрямую может играть youtube, умеет, в отличие от mplayer'а мотать (искать в) роллик(е). И т.п.
Чего фыркать, ну исправили и забыли. Я так понимаю кроме уязвимости они и патчи предложили или нет?
> Чего фыркать, ну исправили и забыли.Дык разработчики VLC не хотят исправлять.
>> Чего фыркать, ну исправили и забыли.
> Дык разработчики VLC не хотят исправлять.Все они исправили, читайте ссылки. СЫкуния просто сама не знает, что хочет.