https://opennet.ru/openforum/vsluhforumID3/109285.html В библиотеке OpenJPEG (http://www.openjpeg.org/) выявлена (http://blog.talosintel.com/2016/09/vulnerability-spotlight-jpeg2000.html) опасная уязвимость (http://www.talosintelligence.com/reports/TALOS-2016-0193/) (CVE-2016-8332 (https://security-tracker.debian.org/tracker/CVE-2016-8332)), которая может привести к выполнению кода злоумышленника при обработке специально оформленных изображений в формате JPEG 2000 в приложениях, использующих функции OpenJPEG для их обработки. Уязвимость вызвана выходом за границы буфера при разборке записей mcc.<br><br><br><br>В том числе, уязвимости подвержены просмотрщики PDF Poppler, MuPDF и Pdfium, использующие OpenJPEG для декодирования встроенных в PDF-файлы изображений, а также некоторые почтовые клиенты, автоматически показывающие прикреплённые к письмам изображения. Проблема устранена в выпуске OpenJPEG 2.1.2 (http://www.openjpeg.org/2016/09/28/OpenJPEG-2.1.2-released).<br><br><br><br>URL: http://blog.talosintel.com/2016/09/vulnerability-spotlight-jpeg2000.html<br>Новость: http://www.openn https://opennet.ru/openforum/vsluhforumID3/109285.html#38 Tue, 04 Oct 2016 06:09:10 GMT &gt; Потеряете данные клиентов или ещё хуже, если они утекут налево. Будете не <br>&gt; только софтину, но и клиентов перезапускать?<br><br>На то они и клиентЫ, что их много. <br>Данные восстанавливаются тащемта. Если надо - ручками. <br>Это у вас в Московии утекут, а тут в Сибири они могут валяться в распечатанном виде - не возьмет никто, разве что в туалете бумага кончится. Я так заполучил схему устройства ЦОД провайдера, у которого 60 000+ абонентов. С номерами AS, ip всех серверов и т.д. Просто валялась в пыли на столе тех. отдела.<br>1с-никам дают права админа домена, чтобы не звонили каждый раз, когда надо железку какую-нибудь подключить или драйвер поставить. А что там за "Сережа из фирмы хрю-му" звонит, и что он будет делать - никто не парится даже. <br>И это не я так делаю, а сложившаяся практика у тех самых клиентов. Про лицензирование говорить вообще не буду. <br> https://opennet.ru/openforum/vsluhforumID3/109285.html#37 Tue, 04 Oct 2016 05:07:47 GMT Потеряете данные клиентов или ещё хуже, если они утекут налево. Будете не только софтину, но и клиентов перезапускать?<br> https://opennet.ru/openforum/vsluhforumID3/109285.html#36 Mon, 03 Oct 2016 10:55:21 GMT &gt; Ровно до того момента, пока ваша лапша не взорвётся в продакшене.<br><br>А watchdog на что? Эх, Семён-семеныч... Перезапустится софтина, и всего делов. Будет каждый день падать - обновим, или перейдем на другую. <br><br><br> https://opennet.ru/openforum/vsluhforumID3/109285.html#34 Mon, 03 Oct 2016 07:05:50 GMT логическая то она может и логическая, но "...Уязвимость вызвана выходом за границы буфера...", следовательно, проверка диапазона таки сработала бы, обвалила бы программу нафиг, а не переписала память в неположенном месте. Хоть и работало бы медленнее. Т.е. был бы в "mcc" записан какой-нибудь ошибочный или сознательнозлоумышленный бред на тему размера/смещений данных/секций, сам программист совершил "логическую ошибку", поверив входным данным, не написал бы кода проверки выхода этих смещений за буфер, но в "нормальном языке" перед тем, как код попытался бы сделать это обращение к памяти, выполнилась бы проверка, добавленная компилятором/рантаймом и вылезло бы исключение или другой род ошибок, но не перетирание памяти.<br> https://opennet.ru/openforum/vsluhforumID3/109285.html#33 Sun, 02 Oct 2016 21:32:11 GMT Вообще-то низкоуровневый язык это не C. <br>Это Ассемблер и, возможно, Форт. Всё.<br> https://opennet.ru/openforum/vsluhforumID3/109285.html#32 Sun, 02 Oct 2016 21:17:04 GMT &gt; ага, ты авторам jvm расскажи что у них проблема в ДНК :)))<br><br>Не без этого. ;)<br>Вообще же, Java - это большой полигон идей и методов программирования. Но от детских ошибок, по крайней мере, старались избавляться с самого начала. На Java2 написан прикладной кодек PNG для мобильных устройств с J2ME, кстати, а там нет доступа к нативным функциям.<br> <br><br><br> https://opennet.ru/openforum/vsluhforumID3/109285.html#31 Sun, 02 Oct 2016 20:41:24 GMT 21 век... "выход за границы буфера"... но вы продолжайте писать на своей таймбомбе С++ и пенять на "плохих разрабов", допускающих ошибки! Ровно до того момента, пока ваша лапша не взорвётся в продакшене.<br> https://opennet.ru/openforum/vsluhforumID3/109285.html#30 Sun, 02 Oct 2016 19:23:33 GMT ага, ты авторам jvm расскажи что у них проблема в ДНК :)))<br> https://opennet.ru/openforum/vsluhforumID3/109285.html#29 Sun, 02 Oct 2016 16:27:54 GMT &gt; На X86 еще начиная с 80186 это делалось единственной инструкцией процессора (bound). <br>&gt; Расово вернуе компиляторы уже тогда фичу эту поддерживали прям из коробки <br>&gt; включенной по дефолту, но такая фича не позволяет "трюкачить" без синтаксического <br>&gt; сахара лазая через (unsigned char*) куда попало.<br><br>Она же вроде довольно дорогая была?<br>Я вот смотрю http://zsmith.co/intel_b.html#bound и на таблички к cmp/je - получается вроде бы (грубо и прикидочно) максимум на уровне "эмуляции" bound с помощью cmp/je. По крайней мере, пока все "штатно" (т.е. "jump not taken"). Случайно не "сахарок" на микрокоде?<br>