В открытой (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
значит до июля уязвимость активно эксплуатировалась. Еще раз становиться очевидно что браузером должен оставаться браузером. Либо в инете надо сидеть с виртуалки.
А до июля эта библиотека в браузере была?
> значит до июля уязвимость активно эксплуатировалась.Ага, как только она в октябре в браузере появилась, так сразу до июля и начала.
Можно подумать, в виртуалках нет уязвимостей, ага.
Так нужно запускать одну виртуалку внутри другой (другой в плане ПО)...
Можно подумать, в других виртуалках нет уязвимостей
> Либо в инете надо сидеть с виртуалки.Ага — каждой программе по jail(8). ;)
А меня и штатная возможность через GStreamer устраивала, отрубил этот кодек из-за ненадобности.
Тоже самое сделал, никаких минусов/изменений не увидел.
>фактически исправления уязвимости были внесены без лишней огласки в кодовую базуГде ссылка на коммит? "Океания всегда воевала с Остазией".
Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP?Вы вот прям точно всё равно уверены что CPP безопасен, и для написания кода без "языковых" ошибок достаточно будет вам заплатить побольше? (Извините за передёргивание если что.)
Или может быть ржавчина (rust-lang) всё-таки имеет смысл? И может быть JVM не позволяет такого вида ошибок? (При всей отстойности JVM по ооочень широкому спектру других вещей.)
(Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая психология перед очевидным багом, привязанным к конкретному языку и практически невозможная на rust/jvm.)
> (Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая
> психология перед очевидным багом, привязанным к конкретному языку и практически невозможная
> на rust/jvm.)Credo, quia absurdum
JVM сам по себе дает массу возможностей отстрелить себе ногу. И для таких низкоуровневых вещей, как видеокодеки - любой managed код это бестолковая трата ресурсов. Зачастую даже для видеокодеков делают оптимизации ассемблерными вставками - там, где это очень критично, не то что cpp.Управляемый код имеет смысл в уровнях много выше, базовая система обязана быть настолько производительной, насколько это возможно. Для безопасности C++ существуют тонны софта, обеспечивающего анализ кода и его тестирование, - как открытые, так и проприетарные. И конкретно Mozilla Foundation вполне располагает средствами, чтобы купить необходимый для контроля софт и время специалистов-аналитиков.
C++ никогда не был и не будет безопасным языком. Это бред. Но в текущих условиях он обеспечивает хороший баланс скорости и синтаксических/функциональных плюшек.
Знаете, эти плюшки скорее время тратят, нежели экономят. Я припоминаю, что неделю отлавливал языковые баги в C++, а потом плюнул и переписал всё за 3 дня на Common Lisp. И получил готовый к работе код.В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс. Единственный вариант, когда я могу на нём писать быстро - это использовать С++ только возможности языка C плюс одна или две плюшек C++ (Полиморфизм, например, бывает очень кстати). А в общем случае весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и изобилует багами, что печально.
> весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и
> изобилует багами, что печально.Ты всё правильно для себя решил. Не получается - не трожь
Я про синтаксический сахар в принципе - мне, например, очень нравился когда-то ассемблер, но при всём - более-менее серьезный проект на нем не написать. Макроассемблеры же очень быстро по существу начинают догонять Си (в процессе дописывания макросов) - то есть уход от низкого уровня.Плюсы хороши большой кодовой базой, массой народа на них работающих, множеством отработанных техник и рецептов. Сейчас порог входа я бы оценил как равный любому "детский" паскаль/бейсик. CL - минимум в этом плане проигрывает (впрочем, как и любой другой функциональный язык).
С++ достаточно выразительный, чтобы на нем можно было написать что угодно - от ОС до приложений и скриптов.
ЗЫ Полиморфизм и объекты - это и есть основной инкремент относительно Си.
> Плюсы хороши большой кодовой базой, массой народа на них работающих, множеством отработанных
> техник и рецептов.И это основной минус. Масса народа, которая в общем-то не разбирается в языке, и которая лезет давать свои "дельные" советы. А разбираться в языке сложно из-за переусложнённых правил вычисления. Вон в институте Макса Планка ребята до сих пор находят ошибки в стандарте, так что разбирается ли хоть кто-то в этом языке - вопрос тот ещё.
На 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
> В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс.Пока вы не видите - игроделы на нем здоровенные проекты наворачивают, например. И да, их скорость и предсказуемость поведения - интересует. По этим же причинам на них пишут требовательные к скорости программы, которые на сях уже стало слишком разлаписто писать.
Спасибо за ответ.Если вдуматься, на самом деле, то я ни в одном месте не говорил про то плохой ли язык c++. Я прошу признать одну конкретную проблему.
Кстати, Mozilla Foundation вроде и должна "распологать средствами чтобы ***", но на самом деле и не распологает ими: они сами на каких-то из видяшек говорили что по-прежнему > 90% ошибок это разыменовывания null pointer-ов и прочие именно языковые ловушки. Да и в Яндексе, если верить другой видяшке, тоже допускаются такие ошибки. То есть это уходит в продакшон, потом в конце концов одна из машинок заваливается с ошибкой. Потом это инспектируют, с какой-то вероятностью находят ошибку, чинят, релизят новую версию.. And the circle goes on.
>[оверквотинг удален]
> Если вдуматься, на самом деле, то я ни в одном месте не
> говорил про то плохой ли язык 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 в тех местах, где производительность критична.
Эм... не то чтобы флейм, но некоторая корректировка. Я бы не называл iOS-код unmanaged. Там вполне приличный подсчет ссылок. Что до отзывчивости андроида - когда гугл таки собрался и сделал AOT в Android 5 жизнь резко улучшилась. Так что дело там скорее в превосходстве заранее скомпилированного кода перед JIT.
Ещё раз, вы считаете что я говорю что CPP плохой/неподходящий язык?
Я это где-то говорил или имел в виду, по-вашему?
Иными словами,
я за -- называть плюсы хорошим компромиссом для риал-таймовых задач или тех где высокие требования к ресурсам.
я против -- притворяться что не видишь слона в комнате (небезопасность).
> я против -- притворяться что не видишь слона в комнате (небезопасность).У каждого языка свой небезопасный слон в комнате. У одного это прямой доступ к памяти, у другого динамическая типизация и duck typing, а значит возможность подсовывания объекта другого типа, у третьего injections, у четвертого eval() (частный случай injections), у пятого уязвимости в интерпретаторе или VM, у шестого излишняя зависимость от переменных окружения (частный случай уязвимости в интерпретаторе). NULL/Null/null/nil, опять таки, не только в С/С++ есть.
Уже ж несколько лет назад это обсасывали на форумах.
> Уже ж несколько лет назад это обсасывали на форумах.Ну вон в вебе используют пыхи, питоны и прочие. В результате то иньекции чего попало, то загрузка абы каких файлов, то еще какая-нибудь хрень. И в результате теперь системы в основном ломают через дырявую вебню. Си теперь конечно стал менее виноват, а вот взломов меньше не стало. Даже больше. Да что там, даже целые червяки появились, долбящие вебню на автомате. Не багом - так глупым паролем админа.
>> Уже ж несколько лет назад это обсасывали на форумах.
> Ну вон в вебе используют пыхи, питоны и прочие. В результате то
> иньекции чего попало, то загрузка абы каких файлов, то еще какая-нибудь
> хрень. И в результате теперь системы в основном ломают через дырявую
> вебню. Си теперь конечно стал менее виноват, а вот взломов меньше
> не стало. Даже больше. Да что там, даже целые червяки появились,
> долбящие вебню на автомате. Не багом - так глупым паролем админа.Таки я вас уверяю - в вебе образца 97-98 года (когда еще была масса cgi, писаных на C/C++) сплошь и рядом в норме вещей были stack overflow. Пыха тогда просто не было, да, перловка тоже давала прикурить (салют Леше Павлову, если кто помнит такого).
Построчная проверка кода.
Блин, ну что ж вам свербит-то так? Да пишите на чём хотите, и другим не мешайте. Сколько можно уже по кругу всё это обсуждать..
> Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP?Толстота.
Вообразил себе оппонентов, вложил им в уста воображаемые аргументы и начал героически их развенчивать, PROFIT!
Взрослеть то собираешься?>И может быть JVM не позволяет такого вида ошибок?
JVM написана на плюсах, конец религии
> Вы вот прям точно всё равно уверены что CPP безопасен,Чего бы это вдруг? Си++ позволяет себе прострелить пятки при желании. Единственная проблема - языки которые делают добавочные проверки на видеокодеке провалятся по производительности. Раза так в три. И юзеры, особенно с слабыми компьютерами, обложат такой кодек матом. Особенно при попытках посмотреть что-нибудь в разрешении поболее почтовой марки.
> (При всей отстoйности JVM по ооочень широкому спектру других вещей.)
Вы, конечно, извините, но кому и зачем надо кодек, тормозящий в 3 раза сильнее и икающий в моменты когда GC приспичило собрать мусор? Это сойдет как PoC, показать "ява не тормозит" всему миру. Но на практике этим будет пользоваться разве что сам автор, которому свое не пахнет.
> икающий в моменты когда GC приспичило собрать мусорЯ не интересовался именно джавой, но мне несколько удивительно слышать, что джава так и не научилась гонять gc в отдельном потоке. Уж кому-кому, а жабе с её популярностью и использованием во всех щелях это просто необходимо. В связи с этим вопрос: это вы чисто умозрительно предполагаете икание у java-кодека, или на своём опыте сталкивались? Расскажете как воспроизвести?
Ответ такой что нет, это было исключительно умозрительное предположение анонима, и совершенно неверное. В JVM gc-шка является настраиваемой, т.е. ты можешь указать её сам при старте jvm. Версия которая не делает "stop the world" возникла уже очень давно, и вроде по дефолту и запускается в JVM тоже уже давно. Т.е. gc действительно идёт в параллельном потоке.При всём при этом, я вообще хотел лишь обратить внимание на безопасность c/cpp.
По факту писать именно кодеки я ни за что на JVM не рекомендую. Будет гигантское потребление памяти и медленная скорость работы (хоть и "плавная", без пауз). Касательно рекоммендаций, мне кажется кодеки надо писать на rust-lang. Или, если этот язык кажется недостаточно стабильным, то по-старинке на c/cpp.
Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё опен соурс называется.
> Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё
> опен соурс называется.Ну потому и называется: читайте сорсы, в них никаких недоговорок нет.
ну написано же, что уязвимости в лисе нет и не было, проблемы?