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

Исходное сообщение
"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."

Отправлено opennews , 30-Ноя-14 23:06 
В открытой (http://www.opennet.me/opennews/art.shtml?num=38662) компанией Cisco библиотеке OpenH264 (https://github.com/cisco/openh264), предоставляющей средства для кодирования и декодирования потоков H.264, выявлена уязвимость (http://tools.cisco.com/security/center/viewAlert.x?alertId=3...), которая может привести к выполнению кода, при обработке специально оформленных данных в приложениях, использующих OpenH264.


Одним из наиболее известных продуктов, использующих OpenH264 для обеспечения поддержки видеокодека H.264, является web-браузер Firefox. Поддержка OpenH264 была добавлена начиная с выпуска Firefox 33 (http://www.opennet.me/opennews/art.shtml?num=40824). По сообщению (https://bugzilla.mozilla.org/show_bug.cgi?id=1105688#c1) разработчиков Mozilla, Firefox не подвержен проблеме, так как несмотря на то, что информация об уязвимости анонсирована только сейчас, фактически исправления уязвимости были внесены (https://github.com/cisco/openh264/pull/1088/files) без лишней огласки в кодовую базу ещё в начале июля и вошли в состав ветки OpenH264 1.1 (https://github.com/cisco/openh264/releases/tag/v1.1), которая используется в Firefox.

URL: http://tools.cisco.com/security/center/viewAlert.x?alertId=3...
Новость: http://www.opennet.me/opennews/art.shtml?num=41157


Содержание

Сообщения в этом обсуждении
"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Ahulinux , 01-Дек-14 00:06 
значит до июля уязвимость активно эксплуатировалась. Еще раз становиться очевидно что браузером должен оставаться браузером. Либо в инете надо сидеть с виртуалки.

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 01-Дек-14 02:05 
А до июля эта библиотека в браузере была?

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Aceler , 01-Дек-14 08:00 
> значит до июля уязвимость активно эксплуатировалась.

Ага, как только она в октябре в браузере появилась, так сразу до июля и начала.


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 01-Дек-14 12:28 
Можно подумать, в виртуалках нет уязвимостей, ага.

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Sergey722 , 01-Дек-14 12:52 
Так нужно запускать одну виртуалку внутри другой (другой в плане ПО)...

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 01-Дек-14 22:10 
Можно подумать, в других виртуалках нет уязвимостей

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено iZEN , 01-Дек-14 14:31 
> Либо в инете надо сидеть с виртуалки.

Ага — каждой программе по jail(8). ;)


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено th3m3 , 01-Дек-14 02:06 
А меня и штатная возможность через GStreamer устраивала, отрубил этот кодек из-за ненадобности.

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноном , 01-Дек-14 10:21 
Тоже самое сделал, никаких минусов/изменений не увидел.

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 01-Дек-14 05:30 
>фактически исправления уязвимости были внесены без лишней огласки в кодовую базу

Где ссылка на коммит? "Океания всегда воевала с Остазией".


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено vn971 , 01-Дек-14 06:13 
Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP?

Вы вот прям точно всё равно уверены что CPP безопасен, и для написания кода без "языковых" ошибок достаточно будет вам заплатить побольше? (Извините за передёргивание если что.)

Или может быть ржавчина (rust-lang) всё-таки имеет смысл? И может быть JVM не позволяет такого вида ошибок? (При всей отстойности JVM по ооочень широкому спектру других вещей.)


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено vn971 , 01-Дек-14 06:17 
(Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая психология перед очевидным багом, привязанным к конкретному языку и практически невозможная на rust/jvm.)

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено kurokaze , 01-Дек-14 11:33 
> (Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая
> психология перед очевидным багом, привязанным к конкретному языку и практически невозможная
> на rust/jvm.)

Credo, quia absurdum


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено JSmith , 01-Дек-14 08:28 
JVM сам по себе дает массу возможностей отстрелить себе ногу. И для таких низкоуровневых вещей, как видеокодеки - любой managed код это бестолковая трата ресурсов. Зачастую даже для видеокодеков делают оптимизации ассемблерными вставками - там, где это очень критично, не то что cpp.

Управляемый код имеет смысл в уровнях много выше, базовая система обязана быть настолько производительной, насколько это возможно. Для безопасности C++ существуют тонны софта, обеспечивающего анализ кода и его тестирование, - как открытые, так и проприетарные. И конкретно Mozilla Foundation вполне располагает средствами, чтобы купить необходимый для контроля софт и время специалистов-аналитиков.

C++ никогда не был и не будет безопасным языком. Это бред. Но в текущих условиях он обеспечивает хороший баланс скорости и синтаксических/функциональных плюшек.


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено freehck , 01-Дек-14 09:18 
Знаете, эти плюшки скорее время тратят, нежели экономят. Я припоминаю, что неделю отлавливал языковые баги в C++, а потом плюнул и переписал всё за 3 дня на Common Lisp. И получил готовый к работе код.

В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс. Единственный вариант, когда я могу на нём писать быстро - это использовать С++ только возможности языка C плюс одна или две плюшек C++ (Полиморфизм, например, бывает очень кстати). А в общем случае весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и изобилует багами, что печально.


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено kurokaze , 01-Дек-14 11:35 
> весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и
> изобилует багами, что печально.

Ты всё правильно для себя решил. Не получается - не трожь


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено F , 01-Дек-14 12:13 
Я про синтаксический сахар в принципе - мне, например, очень нравился когда-то ассемблер, но при всём - более-менее серьезный проект на нем не написать. Макроассемблеры же очень быстро по существу начинают догонять Си (в процессе дописывания макросов) - то есть уход от низкого уровня.

Плюсы хороши большой кодовой базой, массой народа на них работающих, множеством отработанных техник и рецептов. Сейчас порог входа я бы оценил как равный любому "детский" паскаль/бейсик. CL - минимум в этом плане проигрывает (впрочем, как и любой другой функциональный язык).

С++ достаточно выразительный, чтобы на нем можно было написать что угодно - от ОС до приложений и скриптов.

ЗЫ Полиморфизм и объекты - это и есть основной инкремент относительно Си.


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено freehck , 02-Дек-14 07:57 
> Плюсы хороши большой кодовой базой, массой народа на них работающих, множеством отработанных
> техник и рецептов.

И это основной минус. Масса народа, которая в общем-то не разбирается в языке, и которая лезет давать свои "дельные" советы. А разбираться в языке сложно из-за переусложнённых правил вычисления. Вон в институте Макса Планка ребята до сих пор находят ошибки в стандарте, так что разбирается ли хоть кто-то в этом языке - вопрос тот ещё.

На debian-russian я уже неоднократно поднимал треды о проблемах языков С и Cxx. Что примечательно, с пониманием дела отвечали всегда одни и те же люди: в основном программисты на Lisp и Haskell.

> Сейчас порог входа я бы оценил как равный любому "детский" паскаль/бейсик.

Ох. Надо мне каяться: я долго пытался, ловил ошибки присваивания определённых мною объектов, ловил презабавные глюки при использовании cout - и в конце концов так и не вошёл.

Что вообще такое этот "порог входа"? Я вот пишу программу, вроде пишу так, как написано в примерах - а код после компиляции выполняет что угодно, но только не то, что я ожидаю.

А вот со Scheme/CL у меня всё получилось гораздо быстрее, не говоря уже о том, что вообще получилось.

> CL - минимум в этом плане проигрывает (впрочем, как и любой другой функциональный язык).

Ну, начнём с того, что CL - НЕ функциональный язык. А закончим тем, что систем (библиотек) на CL есть ну просто завались. А если вам кажется, что в CL их маловато, то посмотрите на Scheme - в том же Racket их столько, что я думаю могли бы потягаться с С/Сxx.

> С++ достаточно выразительный, чтобы на нем можно было написать что угодно -
> от ОС до приложений и скриптов.

Ну это вы загнули. Это на лиспе можно написать что угодно. Плюс'ы для ОС - это больно жирно, да и не даром ведь ядро на чистом Си пишут. А скрипты... тут DSL всяко удобнее. Не думаю, что я предпочту C++ Perl-у или Bash-у.

> ЗЫ Полиморфизм и объекты - это и есть основной инкремент относительно Си.

Реализация ООП в Cxx сильно страдает. Хотя бы от того, что при изменении полей класса при внешней неизменности методов Вам всё равно необходимо перекомпилировать весь код, который этот класс использует.

Вообще, вот что можно почитать по этому поводу, а то мне перечислять все проблемы уж очень долго будет: http://yosefk.com/c++fqa/defective.html


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 02-Дек-14 06:04 
> В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс.

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


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено vn971 , 01-Дек-14 10:01 
Спасибо за ответ.

Если вдуматься, на самом деле, то я ни в одном месте не говорил про то плохой ли язык c++. Я прошу признать одну конкретную проблему.

Кстати, Mozilla Foundation вроде и должна "распологать средствами чтобы ***", но на самом деле и не распологает ими: они сами на каких-то из видяшек говорили что по-прежнему > 90% ошибок это разыменовывания null pointer-ов и прочие именно языковые ловушки. Да и в Яндексе, если верить другой видяшке, тоже допускаются такие ошибки. То есть это уходит в продакшон, потом в конце концов одна из машинок заваливается с ошибкой. Потом это инспектируют, с какой-то вероятностью находят ошибку, чинят, релизят новую версию.. And the circle goes on.


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено F , 01-Дек-14 12:30 
>[оверквотинг удален]
> Если вдуматься, на самом деле, то я ни в одном месте не
> говорил про то плохой ли язык c++. Я прошу признать одну
> конкретную проблему.
> Кстати, Mozilla Foundation вроде и должна "распологать средствами чтобы ***", но на
> самом деле и не распологает ими: они сами на каких-то из
> видяшек говорили что по-прежнему > 90% ошибок это разыменовывания null pointer-ов
> и прочие именно языковые ловушки. ... То есть это уходит в
> продакшон, потом в конце концов одна из машинок заваливается с ошибкой.
> Потом это инспектируют, с какой-то вероятностью находят ошибку, чинят, релизят новую
> версию.. And the circle goes on.

Говорят, что подавляющее большинство такого прекрасно ловится статическими анализаторами. Проблема же ошибок кода в целом - это проблема явно не языка программирования, а программиста.

Да, никто не спорит, чем строже язык, тем сложнее в нем начудить. Вопрос цены. В данном случае цена - способность кодека выполнять свою задачу. Т.е. (для кодека) работать за минимальное время. Поэтому управляемый код для кодека H.264 - исключен.

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

Стоит делать различие между managed и unmanaged/классическим кодом, ок?

Ориентированный на массы софт - тоже понятно, почему в основном не на управляемом коде (JVM/.Net) - охват аудитории зависит и от поддержки старого железа, т.е. низкой ресурсоемкости - что для managed code неверно как в части памяти, так и в части CPU.

Кстати, показательно (сейчас будет флейм) - managed Андроид по отзывчивости явно сливает unmanaged iOS / Symbian при равном железе. И программисты на Андроиде вынуждены пользоваться NDK в тех местах, где производительность критична.


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Crazy Alex , 01-Дек-14 12:45 
Эм... не то чтобы флейм, но некоторая корректировка. Я бы не называл iOS-код unmanaged. Там вполне приличный подсчет ссылок. Что до отзывчивости андроида - когда гугл таки собрался и сделал AOT в Android 5 жизнь резко улучшилась. Так что дело там скорее в превосходстве заранее скомпилированного кода перед JIT.

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено vn971 , 01-Дек-14 14:46 
Ещё раз, вы считаете что я говорю что CPP плохой/неподходящий язык?
Я это где-то говорил или имел в виду, по-вашему?

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено vn971 , 01-Дек-14 15:09 
Иными словами,
я за -- называть плюсы хорошим компромиссом для риал-таймовых задач или тех где высокие требования к ресурсам.
я против -- притворяться что не видишь слона в комнате (небезопасность).

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 01-Дек-14 18:22 
> я против -- притворяться что не видишь слона в комнате (небезопасность).

У каждого языка свой небезопасный слон в комнате. У одного это прямой доступ к памяти, у другого динамическая типизация и duck typing, а значит возможность подсовывания объекта другого типа, у третьего injections, у четвертого eval() (частный случай injections), у пятого уязвимости в интерпретаторе или VM, у шестого излишняя зависимость от переменных окружения (частный случай уязвимости в интерпретаторе). NULL/Null/null/nil, опять таки, не только в С/С++ есть.

Уже ж несколько лет назад это обсасывали на форумах.


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 02-Дек-14 06:11 
> Уже ж несколько лет назад это обсасывали на форумах.

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


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено F , 08-Дек-14 21:20 
>> Уже ж несколько лет назад это обсасывали на форумах.
> Ну вон в вебе используют пыхи, питоны и прочие. В результате то
> иньекции чего попало, то загрузка абы каких файлов, то еще какая-нибудь
> хрень. И в результате теперь системы в основном ломают через дырявую
> вебню. Си теперь конечно стал менее виноват, а вот взломов меньше
> не стало. Даже больше. Да что там, даже целые червяки появились,
> долбящие вебню на автомате. Не багом - так глупым паролем админа.

Таки я вас уверяю - в вебе образца 97-98 года (когда еще была масса cgi, писаных на C/C++) сплошь и рядом в норме вещей были stack overflow. Пыха тогда просто не было, да, перловка тоже давала прикурить (салют Леше Павлову, если кто помнит такого).


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 01-Дек-14 09:55 
Построчная проверка кода.

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Вася Пупкин , 01-Дек-14 11:25 
Блин, ну что ж вам свербит-то так? Да пишите на чём хотите, и другим не мешайте. Сколько можно уже по кругу всё это обсуждать..

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено kurokaze , 01-Дек-14 11:31 
> Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP?

Толстота.
Вообразил себе оппонентов, вложил им в уста воображаемые аргументы и начал героически их развенчивать, PROFIT!
Взрослеть то собираешься?

>И может быть JVM не позволяет такого вида ошибок?

JVM написана на плюсах, конец религии


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 02-Дек-14 06:08 
> Вы вот прям точно всё равно уверены что CPP безопасен,

Чего бы это вдруг? Си++ позволяет себе прострелить пятки при желании. Единственная проблема - языки которые делают добавочные проверки на видеокодеке провалятся по производительности. Раза так в три. И юзеры, особенно с слабыми компьютерами, обложат такой кодек матом. Особенно при попытках посмотреть что-нибудь в разрешении поболее почтовой марки.

> (При всей отстoйности JVM по ооочень широкому спектру других вещей.)

Вы, конечно, извините, но кому и зачем надо кодек, тормозящий в 3 раза сильнее и икающий в моменты когда GC приспичило собрать мусор? Это сойдет как PoC, показать "ява не тормозит" всему миру. Но на практике этим будет пользоваться разве что сам автор, которому свое не пахнет.



"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Ordu , 02-Дек-14 09:36 
> икающий в моменты когда GC приспичило собрать мусор

Я не интересовался именно джавой, но мне несколько удивительно слышать, что джава так и не научилась гонять gc в отдельном потоке. Уж кому-кому, а жабе с её популярностью и использованием во всех щелях это просто необходимо. В связи с этим вопрос: это вы чисто умозрительно предполагаете икание у java-кодека, или на своём опыте сталкивались? Расскажете как воспроизвести?


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено vn971 , 02-Дек-14 14:54 
Ответ такой что нет, это было исключительно умозрительное предположение анонима, и совершенно неверное. В JVM gc-шка является настраиваемой, т.е. ты можешь указать её сам при старте jvm. Версия которая не делает "stop the world" возникла уже очень давно, и вроде по дефолту и запускается в JVM тоже уже давно. Т.е. gc действительно идёт в параллельном потоке.

При всём при этом, я вообще хотел лишь обратить внимание на безопасность c/cpp.
По факту писать именно кодеки я ни за что на JVM не рекомендую. Будет гигантское потребление памяти и медленная скорость работы (хоть и "плавная", без пауз). Касательно рекоммендаций, мне кажется кодеки надо писать на rust-lang. Или, если этот язык кажется недостаточно стабильным, то по-старинке на c/cpp.


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Аноним , 01-Дек-14 12:28 
Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё опен соурс называется.

"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Нимо Ан , 01-Дек-14 18:45 
> Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё
> опен соурс называется.

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


"В видеокодеке OpenH264 выявлена опасная уязвимость, которая ..."
Отправлено Dragonic , 01-Дек-14 21:26 
ну написано же, что уязвимости в лисе нет и не было, проблемы?