The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В видеокодеке OpenH264 выявлена опасная уязвимость, которая не затронула Firefox

30.11.2014 22:45

В открытой компанией Cisco библиотеке OpenH264, предоставляющей средства для кодирования и декодирования потоков H.264, выявлена уязвимость, которая может привести к выполнению кода, при обработке специально оформленных данных в приложениях, использующих OpenH264.

Одним из наиболее известных продуктов, использующих OpenH264 для обеспечения поддержки видеокодека H.264, является web-браузер Firefox. Поддержка OpenH264 была добавлена начиная с выпуска Firefox 33. По сообщению разработчиков Mozilla, Firefox не подвержен проблеме, так как несмотря на то, что информация об уязвимости анонсирована только сейчас, фактически исправления уязвимости были внесены без лишней огласки в кодовую базу ещё в начале июля и вошли в состав ветки OpenH264 1.1, которая используется в Firefox.

  1. Главная ссылка к новости (http://tools.cisco.com/securit...)
  2. OpenNews: Поддержка VP8 и H.264 становится обязательной для браузеров с WebRTC
  3. OpenNews: Релиз Firefox 33
  4. OpenNews: Компания Cisco опубликовала исходные тексты видеокодека OpenH264
  5. OpenNews: Компания Cisco откроет не требующий отчислений кодек H.264, который будет задействован в Firefox
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/41157-openh264
Ключевые слова: openh264
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.3, Ahulinux (ok), 00:06, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –15 +/
    значит до июля уязвимость активно эксплуатировалась. Еще раз становиться очевидно что браузером должен оставаться браузером. Либо в инете надо сидеть с виртуалки.
     
     
  • 2.4, Аноним (-), 02:05, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +9 +/
    А до июля эта библиотека в браузере была?
     
  • 2.9, Aceler (ok), 08:00, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > значит до июля уязвимость активно эксплуатировалась.

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

     
  • 2.20, Аноним (-), 12:28, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подумать, в виртуалках нет уязвимостей, ага.
     
     
  • 3.24, Sergey722 (ok), 12:52, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Так нужно запускать одну виртуалку внутри другой (другой в плане ПО)...
     
     
  • 4.31, Аноним (-), 22:10, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Можно подумать, в других виртуалках нет уязвимостей
     
  • 2.25, iZEN (ok), 14:31, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Либо в инете надо сидеть с виртуалки.

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

     

  • 1.5, th3m3 (ok), 02:06, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А меня и штатная возможность через GStreamer устраивала, отрубил этот кодек из-за ненадобности.
     
     
  • 2.14, Аноном (?), 10:21, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже самое сделал, никаких минусов/изменений не увидел.
     

  • 1.6, Аноним (-), 05:30, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >фактически исправления уязвимости были внесены без лишней огласки в кодовую базу

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

     
  • 1.7, vn971 (ok), 06:13, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP?

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

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

     
     
  • 2.8, vn971 (ok), 06:17, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    (Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая психология перед очевидным багом, привязанным к конкретному языку и практически невозможная на rust/jvm.)
     
     
  • 3.17, kurokaze (ok), 11:33, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > (Я понимаю что тема психологически не простая. Но отступает ли всё-таки любая
    > психология перед очевидным багом, привязанным к конкретному языку и практически невозможная
    > на rust/jvm.)

    Credo, quia absurdum

     
  • 2.10, JSmith (??), 08:28, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    JVM сам по себе дает массу возможностей отстрелить себе ногу. И для таких низкоуровневых вещей, как видеокодеки - любой managed код это бестолковая трата ресурсов. Зачастую даже для видеокодеков делают оптимизации ассемблерными вставками - там, где это очень критично, не то что cpp.

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

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

     
     
  • 3.11, freehck (ok), 09:18, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Знаете, эти плюшки скорее время тратят, нежели экономят. Я припоминаю, что неделю отлавливал языковые баги в C++, а потом плюнул и переписал всё за 3 дня на Common Lisp. И получил готовый к работе код.

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

     
     
  • 4.18, kurokaze (ok), 11:35, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > весь функционал плюсов использовать не получается, ибо язык сильно переусложнён и
    > изобилует багами, что печально.

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

     
  • 4.19, F (?), 12:13, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я про синтаксический сахар в принципе - мне, например, очень нравился когда-то ассемблер, но при всём - более-менее серьезный проект на нем не написать. Макроассемблеры же очень быстро по существу начинают догонять Си (в процессе дописывания макросов) - то есть уход от низкого уровня.

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

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

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

     
     
  • 5.36, freehck (ok), 07:57, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    И это основной минус Масса народа, которая в общем-то не разбирается в языке, и... большой текст свёрнут, показать
     
  • 4.33, Аноним (-), 06:04, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > В общем, не видел я на практике, чтобы плюс'ы обеспечивали какой-то там баланс.

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

     
  • 3.13, vn971 (ok), 10:01, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за ответ.

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

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

     
     
  • 4.22, F (?), 12:30, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >[оверквотинг удален]
    > Если вдуматься, на самом деле, то я ни в одном месте не
    > говорил про то плохой ли язык 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 в тех местах, где производительность критична.

     
     
  • 5.23, Crazy Alex (ok), 12:45, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Эм... не то чтобы флейм, но некоторая корректировка. Я бы не называл iOS-код unmanaged. Там вполне приличный подсчет ссылок. Что до отзывчивости андроида - когда гугл таки собрался и сделал AOT в Android 5 жизнь резко улучшилась. Так что дело там скорее в превосходстве заранее скомпилированного кода перед JIT.
     
  • 5.26, vn971 (ok), 14:46, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё раз, вы считаете что я говорю что CPP плохой/неподходящий язык?
    Я это где-то говорил или имел в виду, по-вашему?
     
  • 5.27, vn971 (ok), 15:09, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Иными словами,
    я за -- называть плюсы хорошим компромиссом для риал-таймовых задач или тех где высокие требования к ресурсам.
    я против -- притворяться что не видишь слона в комнате (небезопасность).
     
     
  • 6.28, Аноним (-), 18:22, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > я против -- притворяться что не видишь слона в комнате (небезопасность).

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

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

     
     
  • 7.35, Аноним (-), 06:11, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Уже ж несколько лет назад это обсасывали на форумах.

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

     
     
  • 8.39, F (?), 21:20, 08/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Таки я вас уверяю - в вебе образца 97-98 года когда еще была масса cgi, писаных... текст свёрнут, показать
     
  • 2.12, Аноним (-), 09:55, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Построчная проверка кода.
     
  • 2.15, Вася Пупкин (?), 11:25, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Блин, ну что ж вам свербит-то так? Да пишите на чём хотите, и другим не мешайте. Сколько можно уже по кругу всё это обсуждать..
     
  • 2.16, kurokaze (ok), 11:31, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Кстаааати. Что скажут об эпизоде люди, ранее утверждавшие безопасность CPP?

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

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

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

     
  • 2.34, Аноним (-), 06:08, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вы вот прям точно всё равно уверены что CPP безопасен,

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

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

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


     
     
  • 3.37, Ordu (ok), 09:36, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > икающий в моменты когда GC приспичило собрать мусор

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

     
     
  • 4.38, vn971 (ok), 14:54, 02/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ответ такой что нет, это было исключительно умозрительное предположение анонима, и совершенно неверное. В JVM gc-шка является настраиваемой, т.е. ты можешь указать её сам при старте jvm. Версия которая не делает "stop the world" возникла уже очень давно, и вроде по дефолту и запускается в JVM тоже уже давно. Т.е. gc действительно идёт в параллельном потоке.

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

     

  • 1.21, Аноним (-), 12:28, 01/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё опен соурс называется.
     
     
  • 2.29, Нимо Ан (?), 18:45, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Эти и другие недоговорки со стороны Mozilla уже начинают напрягать. А ещё
    > опен соурс называется.

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

     
  • 2.30, Dragonic (ok), 21:26, 01/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ну написано же, что уязвимости в лисе нет и не было, проблемы?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру