В различных реализациях алгоритмов распаковки LZO и LZ4 выявлена (http://blog.securitymouse.com/2014/06/raising-lazarus-20-yea...) опасная уязвимость (CVE-2014-4607), которая присутствует уже около 20 лет и может привести к повреждению областей памяти при распаковке специально оформленных сжатых данных. Проблема вызвана целочисленным переполнением, проявляющимся при обработке больших непрерывных блоков нулевых байтов (более 16Мб).В настоящее время
обозначена (http://www.openwall.com/lists/oss-security/2014/06/26/20) возможность применения уязвимости для совершения DoS-атак, но не исключено, что вызываемое уязвимостью повреждение памяти может быть использовано для организации выполнения кода злоумышленника. При использовании в моногопоточных программах уязвимость может привести к повреждению структур, влияющих на процесс выполнения, что может быть использовано для получения контроля за выполнением нитей или процессов из другого контекста.
Проблему усугубляет то, что, в силу специфики использования LZO/LZ4, уязвимость во многих случаях может быть эксплуатирована удалённо. Кроме того, быстрые и эффективные алгоритмы LZO/LZ4 очень широко используются в программном обеспечении: от ядра Linux, Juniper Junos, MPlayer2, Libav, FFmpeg и OpenVPN до различных встраиваемых платформ и устройств, в том числе автомобильных систем и даже масохода Curiosity. Поддержка сжатия с использованием LZO применяется во многих файловых системах, включая btrfs, squashfs, jffs2 и ubifs. LZ4 применяется в файловой системе ZFS.
Уязвимоcти подвержены все версии пакета lzo1, а также все версии liblzo2 за исключением платформ, на которых при сборе используются макросы LZO_UNALIGNED_OK_8 и LZO_UNALIGNED_OK_4. Проявление уязвимости протестировано на архитектурах x86_64, i386 и ARM. Проблема уже исправлена в выпусках (https://www.kernel.org/) ядра Linux 3.15.2, 3.14.9, 3.4.95 и 3.10.45. В дистрибутивах обновления пока на стадии подготовки. Оценить появление обновлений можно на следующих страницах: Debian (https://www.debian.org/security/), Ubuntu (http://www.ubuntu.com/usn/), CentOS (http://lists.centos.org/pipermail/centos-announce/2014-June/), RHEL (https://access.redhat.com/site/security/updates/active/), Fedora (https://admin.fedoraproject.org/updates/F20), openSUSE (http://lists.opensuse.org/opensuse-security-announce/), SLES (https://www.suse.com/support/update/), Slackware (http://www.slackware.com/security/list.php?l=slackware-secur...), Gentoo (http://www.gentoo.org/security/en/index.xml), OpenBSD (http://www.openbsd.org/security.html), NetBSD (http://www.netbsd.org/support/security/), FreeBSD (http://www.freebsd.org/security/advisories.html).URL: http://blog.securitymouse.com/2014/06/raising-lazarus-20-yea...
Новость: http://www.opennet.ru/opennews/art.shtml?num=40093
libzlo2, блинну теперь марсоходу точно капец
> теперь марсоходу точно капецМарсиане взломают управляющее ПО и устроят весёлые покатушки? :)
>> теперь марсоходу точно капец
> Марсиане взломают управляющее ПО и устроят весёлые покатушки? :)да он вроде на Power-е?
> да он вроде на Power-е?Как раз самое оно для марсиан...
Биткоины на марсоходе майнить - самое оно!
> Биткоины на марсоходе майнить - самое оно!А потом окажется что Сатоши с другой планеты и давным давно "контрольный пакет акций" себе уже намайнил. И вообще - окажется что это был эксперимент. Интересно же посмотреть насколько эти обезьяны могут прокачать технологии, если технологии напрямую добывают бабло, котороге лучший стимул для глупых жадных обезьян :).
Зачем марсианам допотопная техника дикарей?
Можно извлечь немало лулзов, показывая наивным дикарям не то что есть, а то что хочется.
Так вот как он снимает сам себя! А то пишут - склейка из нескольких фото...
> склейка из нескольких фото...Так не врут же. Они просто постеснялись уточнить где именно произведена склейка. Ну не могут же они сообщить руководству что марсоход давно расхакали местные аборигены, извлекающие уйму лулзов?
> libzlo2, блинИли Liblolz2, смотря с какой стороны посмотреть :P.
Ждём юбилейного пятидесятилетнего бага. Двадцатилетний уже находили, если память мне не изменяет.
Не думаю, что из 1965го года хоть что то дошло.
Язык Си, к примеру, только в 1969 разрабатывать начали.
Именно потому, что ничего из '65 ничего не дошло, мы и ждём до сих пор, когда какой-нибудь из дошедших багов успеет состарится в достаточной мере, прежде чем быть обрануженным.
Вот потому и нет багов 65 года, что Си начали разрабатывать в 69-м.
И что такого страшного в Lisp который лет на 10 старше C?
> И что такого страшного в Lisp который лет на 10 старше C?Туева хуча совершенно одинаковых скобочек на все случаи жизни. Разновидностей скобок, блин, людям не хватило. На все один ответ ответ )))))).
Единственно, думаю, в какой-нибудь FORTRAN-библиотеке, написанной на FORTRAN'e, возможно и остались математические баги.
В программе на классическом фортране нет и не может быть багов. Только ошибки в реализации алгоритмов.
> В программе на классическом фортране нет и не может быть багов. Только
> ошибки в реализации алгоритмов.дЫк - "особенности реализации" же, какие такие ашипки? :)
> нет и не может быть багов.Очень смелое и очень некомпетентное заявление.
> Только ошибки в реализации алгоритмов.
А это, типа, не баги? Вообще-то баг == ошибка.
программа — частный случай реализации
В названии "ALGOL 60" ничего не просматривается?К 1965-ому уже IO-монады придумали - http://okmij.org/ftp/Computation/IO-monad-history.html
И не только.
> That person is Peter Landin. His 1965 paper [Landin-1965] anticipated not only IO but also State and Writer monads, call/cc, streams and delayed evaluations, the relation of streams with co-routines, and even stream fusion.
> В названии "ALGOL 60" ничего не просматривается?Вижу динозавров! :)
А в закрытом скорее всего так бы и не нашли.
возможно. но это не ответ на поставленный вопрос.
> но это не ответ на поставленный вопрос.Это почему же? Знавал тут одних. Починили возможность рекурсивного сноса всех файлов по иерархии. И в ченжлог даже не пикнули. Ну да, это вам не bumblebee, где честно признались в обсираке. Разумеется, проприетарь...
Ну да, какой-нибудь MS просто починит тихой сапой и вообще CVE не выпустит.Впрочем, чтобы что-то чинить - надо чтобы было что чинить, для начала. Покажи среди проприетари сколь-нибудь сравнимые алгоритмы? Они где???
RAR ?
> RAR ?Ни разу не видел сообщений что они починили уязвимость. Хотя при сложности формата и алгоритмов как у них - там запросто может чего-нибудь накопаться. Но т.к. бабло побеждает зло, а оно шароварь - скорее всего починят тихой сапой, чтобы репутацию не портить. Кто ж будет покупать бажные программы? :)
> Хотя при сложности
> формата и алгоритмов как у них - там запросто может чего-нибудь
> накопаться.особенно если учесть, например, что там есть няшная VM. теоретически, конечно, она работает в своей песочнице… но.
> особенно если учесть, например, что там есть няшная VM.А что она там выполняет?
>> особенно если учесть, например, что там есть няшная VM.
> А что она там выполняет?идея была такая, что на ней можно всякие фильтры писать, которые сжатие улучшают. типа преобразования e8,ofs32 в e8,addr32 в x86-бинарях и подобное. на практике особо никто не пользовался, насколько знаю. на, любопытствуй:
http://blog.cmpxchg8b.com/2012/09/fun-with-constrained-progr...
https://github.com/taviso/rarvmtoolsв ней, вроде бы, и уязвимости находили. но это уже дальше первых двух ссылок гугля, мне лень.
> практике особо никто не пользовался, насколько знаю.Ухтыб$%. ВНЕЗАПНО.
> в ней, вроде бы, и уязвимости находили. но это уже дальше первых
> двух ссылок гугля, мне лень.Спасибо, ценно. Я как-то всегда считал что архиватору достаточно "пассивного" формата. А оказывается что бывает и вот так... O_O.
Ладно, в качестве спасибов поделюсь еще одним не очень очевидным и не очень приятным наблюдением: если RTFMнуть получше, в N900 GPS таки делается с участием сотового модема - beware.
> Ладно, в качестве спасибов поделюсь еще одним не очень очевидным и не
> очень приятным наблюдением: если RTFMнуть получше, в N900 GPS таки делается
> с участием сотового модема - beware.хм. я как-то даже не задумывался в эту сторону. спасибо, учту и покопаю.
> Я как-то всегда считал что архиватору достаточно "пассивного" формата.так это. mp4, что ли, или какой-то из них, или прототип — тоже ведь имел внутри себя VM, на которой куски декомпрессора работали. тоже с целью адаптивного сжатия под разные потоки. да и zpaq, например…
> так это. mp4, что ли, или какой-то из них, или прототип —
> тоже ведь имел внутри себя VM, на которой куски декомпрессора работали.Что-то не припоминаю VM в mp4. Я правда мпеги изучал в основном на примере mpeg1/2 и простых профайлах MP4, там ничего такого не было. Были обычные I/P/B кадры, потом наворотов вокруг добавили, более эффективное кодирование энтропии и что там еще.
> тоже с целью адаптивного сжатия под разные потоки.В каком выводке стандартов хотя-бы?
> В каком выводке стандартов хотя-бы?я не помню вообще, дошло ли это до стандартов, я не настоящий сварщик. так, слышал когда-то краем уха. идея такая точно была, а слили её потом или нет — не в курсе, пардон.
> RAR ?Вы думаете в RAR уникальные алгоритмы? Они основаны на тех же самых.
В WinRAR была эпичная дырень со спуфингом расширения файла.
http://habrahabr.ru/company/dsec/blog/216785/Не совсем в алгоритме, скорее, в обработке дополнительного поля, которое WinRAR вставляет в архивы.
открытый код помог найти ДРУГИЕ ошибки. а вот найти ВСЕ ошибки он не может.
Интересно, скорость накопления ошибок всегда меньше скорости их исправления?
> Интересно, скорость накопления ошибок всегда меньше скорости их исправления?Раз на раз не приходится. Бывает так что чинят 2, сажают 1. А бывает и так что "починил 8 известных ошибок из 35. Теперь в проекте 49 известных ошибок...".
Вряд ли здесь присутсвуют авторы этого CVE.
А где ты видишь, что он не помогает?
Эти студни так активны только летом?
> Эти студни так активны только летом?Да если б, это уже взрослые особи.
А тебя сильно утешит, что в проприетарщине и твоем любимом коде под лицензией BSD, который при первой возможности прикроют проприетарщики, уязвимости не найдут никогда?Надеюсь, ты все-таки далек от написания серьезных продуктов. Из-за таких, как ты, потом народ мучается догадками, кто и как поимел их сеть. Код-то не проверишь, в отличие от продуктов, которые вызывают у тебя зависть и такую дикую попоболь.
> А тебя сильно утешит, что в проприетарщине и твоем любимом коде под
> лицензией BSD,ЧСХ, LZ4 - таки под BSD. И у проприетарщиков в их appliance он ничуть не менее бажный. Только в силу зажатых исходников там надеяться придется разве что на милость блобмейкера.
>> В различных реализациях алгоритмов распаковки LZO и LZ4 выявлена опасная уязвимость (CVE-2014-4607), которая присутствует уже около 20 лет и может привести к повреждению областей памяти при распаковке специально оформленных сжатых данных.
> Подскажите - это так помог открытый код искать ошибки?я был не прав в #14, они начали рефлексировать:-) мишенька в #35 вообще умничка:)
> я был не прав в #14Уважаю.
За грамотность?
> За грамотность?Школота никогда не скажет "я не прав". Их физиологически от этого бомбашит на части - кактузикгрелку, да :)
Вот Майкл похоже в уме галочку и поставил что Тигар - не школота. Уже не плохо :)
PS: Миру пис, фолкс! Дожди кончились - все на пляж!
> Школота
> физиологически
> бомбашит
> кактузикгрелкуНеШкoлота на опеннете :).
Это такое место бро, я бы мог о чём то высоком, но ...
"Поручик! Тут же никто этого не оценит!" (С)
16mb для x86_86, для 64 число слишком велико. Ещё один повод обновить арх-ру :)
практически весь арм пока 32битный.
Работает не трогай! Поэтому за 20 лет ни кто аудит и не делал.
страница по openbsd к делу отношения не имеет. в портах уже давно обновили
> в портах уже давно обновилиА в пакетах обновят, как всегда, в следующем релизе - 1 ноября.
> А в пакетах обновят, как всегда, в следующем релизе - 1 ноября.да, успеет в следующий релиз. а мог бы и не успеть. :)
> А в пакетах обновят, как всегда, в следующем релизе - 1 ноября.Правильно, должны же кидизы наконец получить себе бесплатный хостинг на каникулы?!
http://fastcompression.blogspot.ru/2014/06/debunking-lz4-20-...
судя по этому описанию уязвимость не очень опасная - нужна 32битная система и блок больше 8 Мб (обычно размер блока меньше)
> http://fastcompression.blogspot.ru/2014/06/debunking-lz4-20-...Спасибо, интересный разбор характерного полёта.
---
Second, the author claims to have found this subtle risk through careful code study on its own. This is not true. The risk was identified by Ludwig Strigeus, the creator of µTorrent, more than one year ago. Ludwig made a very fine job at describing the risk. Instead of trying to make a headline, he proposed a solution for it. That's a difference. The risk was finally plugged some time ago, before DonB published his article. Why so much time you would ask?
---
> Well, because there was no real-world risk.Автор такой крутой - за все использования либы головой отвечает. Зато как это в CVE оформили - сразу подорвался оправдания писать. Лучше б он год назад это законопатил - тогда не пришлось бы год спустя так оправдываться. Упование на то что блок нигде и никогда не превысит 16М - это из разряда "640Кб хватит всем".
Да он ни на что не уповает, он пишет что ни в одной известной ему реализации не используется блок в 16М, по стандарту для LZ4 он 4М и т.п.... хотя судя по сообщению товарища, который поднял бучу ffmpeg/libav отличились в этом плане (удаленное выполнение кода), но они уже выпустили патч.
> по стандарту для LZ4 он 4МЕсли обратить внимание, 4M там для поточной версии. Мягко говоря, с сжатыми *потоками* работают далеко не все. Для блочного вариатна типовой блок 8Мб, но есть одно "но". Это подразумевает дефолтный формат. А те или иные апликухи, которым 8Мб оказалось мало - могут использовать свой формат и чисто технически могут скормить либе и более крупные блоки. И вот так эксплойт вполне себе сработает...
> но они уже выпустили патч.
Тем не менее, со стороны автора либы так делать не очень хорошо. Особенно если он целый год был в курсе такой возможности.
Раскладывать минное поле в таких либах - не есть правильно. Так что то что в большинстве программ оно неэксплуатируемо - это, конечно, хорошо. Но программ много разных бывает, расписываться за всю планету как-то достаточно безответственно.> ffmpeg/libav отличились в этом плане (удаленное выполнение кода)
Не совсем понимаю как выглядит именно выполнение кода в том же LZO, ибо баг специфичен и дает очень ограниченные возможности манипуляции памятью. В LZ4 - там более интересно, это еще может быть.
> Спасибо, интересный разбор характерного полёта.Что интересно, автор снес из бложика комент, указывавший на то что ffmpeg/libav вполне могут пострадать из-за дырки. Видимо неудобно ему замечать такие вещи. Вот те раз - подумал Штирлиц. Зачетный демарш...