В библиотеке OpenJPEG (http://www.openjpeg.org/) выявлена (http://blog.talosintel.com/2016/09/vulnerability-spotlight-j...) опасная уязвимость (http://www.talosintelligence.com/reports/TALOS-2016-0193/) (CVE-2016-8332 (https://security-tracker.debian.org/tracker/CVE-2016-8332)), которая может привести к выполнению кода злоумышленника при обработке специально оформленных изображений в формате JPEG 2000 в приложениях, использующих функции OpenJPEG для их обработки. Уязвимость вызвана выходом за границы буфера при разборке записей mcc.В том числе, уязвимости подвержены просмотрщики PDF Poppler, MuPDF и Pdfium, использующие OpenJPEG для декодирования встроенных в PDF-файлы изображений, а также некоторые почтовые клиенты, автоматически показывающие прикреплённые к письмам изображения. Проблема устранена в выпуске OpenJPEG 2.1.2 (http://www.openjpeg.org/2016/09/28/OpenJPEG-2.1.2-released).
URL: http://blog.talosintel.com/2016/09/vulnerability-spotlight-j...
Новость: http://www.opennet.ru/opennews/art.shtml?num=45259
И... Pdfium перетягивают в Firefox.
в OpenBSD оно работает?
Кушайте C полной ложкой, господа.
Только вот уязвимость найдена и исправлена и всё отлично, а твоя Ява будет подаваться на лопате всю её жизнь. Кушай дальше.
Соломенное чучело - кроме Явы полно хороших низкоуровневых языков с проверкой границ. Даже тот же C++ с std::array и std::vector.
И чем вызов at() отличается от ручной проверки в Си? Тебе же, явисту, даже в голову не приходит, что обращение к элементу вектора через [] никаких проверок не производит. Иди не тормози дальше.
C++ там будут те же грабли, только глубже зарытые. А на остальных низкоуровневых языках с проверкой массивов (D?) сколько народу пишет-то? А какой-нить Go вообще не предназначен для библиотек...
> Соломенное чучело - кроме Явы полно хороших низкоуровневых языков с проверкой границ.
> Даже тот же C++ с std::array и std::vector.А теперь представь себе что декомпрессор будет на каждый копируемый байт проверку границ гонять. Занимающую дольше чем остальное вместе взятое. Представляешь себе - была у пользователя система играющая FullHD без напряга. А тут приходишь ты такой из себя хороший и заявляешь что все должны смотреть 360p во имя безопасности. Больше при таком оверхеде та система уже не потянет.
Дык хорошо же! Дядям из интела тоже кушать надо, а тут вы со своими оверхедами, понимаешь...
> А теперь представь себе что декомпрессор будет на каждый копируемый байт проверку
> границ гонять. Занимающую дольше чем остальное вместе взятое. Представляешь себе -
> была у пользователя система играющая FullHD без напряга.А теперь представь себе, что побайтовое копирование уже само по себе хороший тормоз.
Посмотри при случае в
http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=sysdep...А теперь представь себе, что еще можно и перед копирванием проверять размеры. И потом копировать байты без проверок. Классно да?
Вообще-то низкоуровневый язык это не C.
Это Ассемблер и, возможно, Форт. Всё.
Кроме явы есть куча других языков.
> Кроме явы есть куча других языков.Текущие разработки в этом поле - Agda, Idris, F*.
"Нам не нужны проверки границ массивов, так как это замедляет скорость", - говорили они... Ха-ха-ха.
Напишите ему уже ему ядро FreeBSD на Java.
Да чего уж мелочиться -- нужно попросить Баллмера(или кто там нынче у руля) переписать винду на Яве.
Зачем? Там, вродь, и так дыр хватает… Или уже не хватает?
там есть специальный эмулятор торможения, так что ява там не нужна
>переписать винду на Яве.я слышал про одну конторку, так они ОСь для мобил тоже на Яве написали. теперь отмыться не могут.
> Да чего уж мелочиться -- нужно попросить Баллмера(или кто там нынче у
> руля) переписать винду на Яве.Странно, что не на Фортране - он тоже древний и тоже с проверками границ.
> "Нам не нужны проверки границ массивов, так как это замедляет скорость", - говорили они... Ха-ха-ха.На X86 еще начиная с 80186 это делалось единственной инструкцией процессора (bound). Расово вернуе компиляторы уже тогда фичу эту поддерживали прям из коробки включенной по дефолту, но такая фича не позволяет "трюкачить" без синтаксического сахара лазая через (unsigned char*) куда попало.
> включенной по дефолту, но такая фича не позволяет "трюкачить" без синтаксического
> сахара лазая через (unsigned char*) куда попало.По поводу чего сломаются чуть более чуть все алгоритмы сжатия, шифрования и проч.
> На X86 еще начиная с 80186 это делалось единственной инструкцией процессора (bound).
> Расово вернуе компиляторы уже тогда фичу эту поддерживали прям из коробки
> включенной по дефолту, но такая фича не позволяет "трюкачить" без синтаксического
> сахара лазая через (unsigned char*) куда попало.Она же вроде довольно дорогая была?
Я вот смотрю http://zsmith.co/intel_b.html#bound и на таблички к cmp/je - получается вроде бы (грубо и прикидочно) максимум на уровне "эмуляции" bound с помощью cmp/je. По крайней мере, пока все "штатно" (т.е. "jump not taken"). Случайно не "сахарок" на микрокоде?
> "Нам не нужны проверки границ массивов, так как это замедляет скорость", -
> говорили они... Ха-ха-ха.Так сейчас при компиляции делают. :-)
Загляните в их исходники. Если так подходить к написанию кода, то не удивительно, что где-то упадёт.
> Кушайте C полной ложкой, господа.Ты только представь себе, в программах случаются ошибки. В любых программах, проприетарных и открытых, на любом ЯП. Некоторые из ошибок ведут к проблемам безопасности. Если тебе это не нравится, единственный вариант - стать луддитом и прекратить пользоваться ПО.
> Ты только представь себе, в программах случаются ошибки.Но такие "детские" ошибки случаются только в программах на Си. ДНК у этого языка такой, что ж поделаешь, и хомячки упорно продолжают навешивать на этот сломанный набор всё новые в том числе аппаратные фичи, подбирая удачные маркетинговые названия: NX-bit, Stack Smashing Protector, Capsicum и т.д.. Это чтобы продавалось всякая дырявая хрень получше. ;))
Ошибка была логическая и связана с "при разборе записей mcc". Никакая автоматическая проверка диапазонов эту ошибку не исправила бы. Скорее наоборот -- подобные действия маскировали бы эту проблему.
И что в итоге? Паразитных проверок нет, ошибки нет и все счастливы. Один только Изя сердито топчет ножками, трясёт кулачками в монитор и чего-то там фыркает про Яву.
логическая то она может и логическая, но "...Уязвимость вызвана выходом за границы буфера...", следовательно, проверка диапазона таки сработала бы, обвалила бы программу нафиг, а не переписала память в неположенном месте. Хоть и работало бы медленнее. Т.е. был бы в "mcc" записан какой-нибудь ошибочный или сознательнозлоумышленный бред на тему размера/смещений данных/секций, сам программист совершил "логическую ошибку", поверив входным данным, не написал бы кода проверки выхода этих смещений за буфер, но в "нормальном языке" перед тем, как код попытался бы сделать это обращение к памяти, выполнилась бы проверка, добавленная компилятором/рантаймом и вылезло бы исключение или другой род ошибок, но не перетирание памяти.
А ява на чём написана? о щи...
Может откажешься уже от явы, FreeBSD.
И т.к. жизнь тоже не безопасная штука, и от неё откажешься?
*ява- остров, сигареты, исторический драндулет двухколесной компановки;
**жаба- мем, амфибия, язык программирования.
ага, ты авторам jvm расскажи что у них проблема в ДНК :)))
> ага, ты авторам jvm расскажи что у них проблема в ДНК :)))Не без этого. ;)
Вообще же, Java - это большой полигон идей и методов программирования. Но от детских ошибок, по крайней мере, старались избавляться с самого начала. На Java2 написан прикладной кодек PNG для мобильных устройств с J2ME, кстати, а там нет доступа к нативным функциям.
21 век... "выход за границы буфера"... но вы продолжайте писать на своей таймбомбе С++ и пенять на "плохих разрабов", допускающих ошибки! Ровно до того момента, пока ваша лапша не взорвётся в продакшене.
> Ровно до того момента, пока ваша лапша не взорвётся в продакшене.А watchdog на что? Эх, Семён-семеныч... Перезапустится софтина, и всего делов. Будет каждый день падать - обновим, или перейдем на другую.
Потеряете данные клиентов или ещё хуже, если они утекут налево. Будете не только софтину, но и клиентов перезапускать?
> Потеряете данные клиентов или ещё хуже, если они утекут налево. Будете не
> только софтину, но и клиентов перезапускать?На то они и клиентЫ, что их много.
Данные восстанавливаются тащемта. Если надо - ручками.
Это у вас в Московии утекут, а тут в Сибири они могут валяться в распечатанном виде - не возьмет никто, разве что в туалете бумага кончится. Я так заполучил схему устройства ЦОД провайдера, у которого 60 000+ абонентов. С номерами AS, ip всех серверов и т.д. Просто валялась в пыли на столе тех. отдела.
1с-никам дают права админа домена, чтобы не звонили каждый раз, когда надо железку какую-нибудь подключить или драйвер поставить. А что там за "Сережа из фирмы хрю-му" звонит, и что он будет делать - никто не парится даже.
И это не я так делаю, а сложившаяся практика у тех самых клиентов. Про лицензирование говорить вообще не буду.