| |
В различных реализациях алгоритмов распаковки LZO и LZ4 выявлена опасная уязвимость (CVE-2014-4607), которая присутствует уже около 20 лет и может привести к повреждению областей памяти при распаковке специально оформленных сжатых данных. Проблема вызвана целочисленным переполнением, проявляющимся при обработке больших непрерывных блоков нулевых байтов (более 16Мб).
В настоящее время
обозначена возможность применения уязвимости в LZO для совершения DoS-атак и теоретически для организации выполнения кода злоумышленника. При использовании LZO в многопоточных программах уязвимость может привести к повреждению структур, влияющих на процесс выполнения, что может быть использовано для получения контроля за выполнением нитей или процессов из другого контекста. Особенность работы алгоритма LZ4 делает возможность организации выполнения кода более реалистичной, так как в результате атаки можно изменить указатель по заданному смещению и переписать часть структур, влияющих на выполнение кода.
Проблему усугубляет то, что, в силу специфики использования LZO/LZ4, уязвимость во многих случаях может быть эксплуатирована удалённо. Кроме того, быстрые и эффективные алгоритмы LZO/LZ4 очень широко используются в программном обеспечении: от ядра Linux, Juniper Junos, MPlayer2, Libav, FFmpeg и OpenVPN до различных встраиваемых платформ и устройств, в том числе автомобильных систем и даже марсохода Curiosity. Поддержка сжатия с использованием LZO применяется во многих файловых системах, включая btrfs, squashfs, jffs2 и ubifs. LZ4 применяется в файловой системе ZFS.
Уязвимоcти подвержены все версии пакетов lzo1, lz4 и liblzo2 (за исключением платформ, на которых при сборке используются макросы LZO_UNALIGNED_OK_8 и LZO_UNALIGNED_OK_4), а также многие сторонние реализации LZO и LZ4, входящие в состав различных библиотек и продуктов. Проявление уязвимости протестировано на архитектурах x86_64, i386 и ARM. Проблема уже исправлена в выпусках ядра Linux 3.15.2, 3.14.9, 3.4.95 и 3.10.45. В дистрибутивах обновления пока на стадии подготовки. Оценить появление обновлений можно на следующих страницах: Debian, Ubuntu, CentOS, RHEL, Fedora, openSUSE, SLES, Slackware, Gentoo, OpenBSD, NetBSD, FreeBSD.
|
|
- Главная ссылка к новости (http://blog.securitymouse.com/2014/06/ra...)
| Тип: Интересно / Проблемы безопасности | Ключевые слова: lzo, lz4, security, (найти похожие документы) | При перепечатке указание ссылки на opennet.ru обязательно | Реклама |
id=adv>
| |
4.79, Серж, 04:55, 28/06/2014 [^] [ответить] [смотреть все] | +/– |
Биткоины на марсоходе майнить - самое оно!
| | | 3.9, Аноним, 11:46, 27/06/2014 [ ^] [ ответить] [ смотреть все] +9 +/–
Зачем марсианам допотопная техника дикарей?
2.38, Аноним, 15:06, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] +/–
1.3, Ordu, 10:40, 27/06/2014 [ответить] [смотреть все] +2 +/–
Ждём юбилейного пятидесятилетнего бага. Двадцатилетний уже находили, если память мне не изменяет.
3.10, жабабыдлокодер, 11:47, 27/06/2014 [ ^] [ ответить] [ смотреть все] +3 +/–Вот потому и нет багов 65 года, что Си начали разрабатывать в 69-м ... весь текст скрыт [ показать] 3.11, Штунц, 11:52, 27/06/2014 [ ^] [ ответить] [ смотреть все] +/–Единственно, думаю, в какой-нибудь FORTRAN-библиотеке, написанной на FORTRAN e, ... весь текст скрыт [ показать] 5.86, Аноним, 09:12, 28/06/2014 [ ^] [ ответить] [ смотреть все] +/–Очень смелое и очень некомпетентное заявление А это, типа, не баги Вообще-то б... весь текст скрыт [ показать] 5.95, Аноним, 14:26, 29/06/2014 [ ^] [ ответить] [ смотреть все] [ к модератору] +/–программа 8212 частный случай реализации... весь текст скрыт [ показать] 3.53, rob pike, 16:35, 27/06/2014 [ ^] [ ответить] [ смотреть все] +1 +/–В названии ALGOL 60 ничего не просматривается К 1965-ому уже IO-монады придум... весь текст скрыт [ показать] 2.17, Аноним, 12:24, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] +3 +/– 2.18, Аноним, 12:27, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] –1 +/–Ну да, какой-нибудь MS просто починит тихой сапой и вообще CVE не выпустит Впро... весь текст скрыт [ показать] [ показать ветку] |
5.80, arisu, 05:29, 28/06/2014 [^] [ответить] [смотреть все] | +/– |
> Хотя при сложности
> формата и алгоритмов как у них - там запросто может чего-нибудь
> накопаться.
особенно если учесть, например, что там есть няшная VM. теоретически, конечно, она работает в своей песочнице… но.
| | |
|
7.87, arisu, 09:12, 28/06/2014 [^] [ответить] [смотреть все] | +/– |
>> особенно если учесть, например, что там есть няшная VM.
> А что она там выполняет?
идея была такая, что на ней можно всякие фильтры писать, которые сжатие улучшают. типа преобразования e8,ofs32 в e8,addr32 в x86-бинарях и подобное. на практике особо никто не пользовался, насколько знаю. на, любопытствуй:
http://blog.cmpxchg8b.com/2012/09/fun-with-constrained-programming.html
https://github.com/taviso/rarvmtools
в ней, вроде бы, и уязвимости находили. но это уже дальше первых двух ссылок гугля, мне лень.
| | |
|
9.92, arisu, 18:27, 28/06/2014 [^] [ответить] [смотреть все] | +/– |
> Ладно, в качестве спасибов поделюсь еще одним не очень очевидным и не
> очень приятным наблюдением: если RTFMнуть получше, в N900 GPS таки делается
> с участием сотового модема - beware.
хм. я как-то даже не задумывался в эту сторону. спасибо, учту и покопаю.
| | | 9.93, arisu, 18:30, 28/06/2014 [ ^] [ ответить] [ смотреть все] +/–
> Я как-то всегда считал что архиватору достаточно "пассивного" формата.
так это. mp4, что ли, или какой-то из них, или прототип — тоже ведь имел внутри себя VM, на которой куски декомпрессора работали. тоже с целью адаптивного сжатия под разные потоки. да и zpaq, например…
4.70, Аноним, 18:43, 27/06/2014 [ ^] [ ответить] [ смотреть все] +/–Вы думаете в RAR уникальные алгоритмы Они основаны на тех же самых ... весь текст скрыт [ показать] 2.24, бедный буратино, 13:02, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] +3 +/–открытый код помог найти ДРУГИЕ ошибки а вот найти ВСЕ ошибки он не может ... весь текст скрыт [ показать] [ показать ветку] 2.26, Аноним, 13:19, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] +/– 2.29, Аноним, 13:55, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] +/– 2.32, Аноним, 14:17, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] +/– 2.34, Аноним, 14:41, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] +/–А тебя сильно утешит, что в проприетарщине и твоем любимом коде под лицензией BS... весь текст скрыт [ показать] [ показать ветку] 2.42, тигар, 15:18, 27/06/2014 [ ^] [ ответить] [ смотреть все] [ показать ветку] –1 +/–я был не прав в 14, они начали рефлексировать - мишенька в 35 вообще умничка ... весь текст скрыт [ показать] [ показать ветку]
1.13, pansa, 12:12, 27/06/2014 [ответить] [смотреть все] +/–
16mb для x86_86, для 64 число слишком велико. Ещё один повод обновить арх-ру :)
1.28, Аноним, 13:36, 27/06/2014 [ответить] [смотреть все] +/–Работает не трогай Поэтому за 20 лет ни кто аудит и не делал ... весь текст скрыт [ показать]
2.50, quiet, 15:34, 27/06/2014 [^] [ответить] [смотреть все] [показать ветку] +/–
1.33, Anton, 14:32, 27/06/2014 [ответить] [смотреть все] +1 +/–
http://fastcompression.blogspot.ru/2014/06/debunking-lz4-20-years-old-bug-myt
судя по этому описанию уязвимость не очень опасная - нужна 32битная система и блок больше 8 Мб (обычно размер блока меньше)
|
4.76, Elhana, 01:42, 28/06/2014 [^] [ответить] [смотреть все] | +/– |
Да он ни на что не уповает, он пишет что ни в одной известной ему реализации не используется блок в 16М, по стандарту для LZ4 он 4М и т.п.... хотя судя по сообщению товарища, который поднял бучу ffmpeg/libav отличились в этом плане (удаленное выполнение кода), но они уже выпустили патч.
|
| | 5.89, Аноним, 11:17, 28/06/2014 [ ^] [ ответить] [ смотреть все] +/–Раскладывать минное поле в таких либах - не есть правильно Так что то что в бол... весь текст скрыт [ показать] 3.88, Аноним, 11:12, 28/06/2014 [ ^] [ ответить] [ смотреть все] +/–Что интересно, автор снес из бложика комент, указывавший на то что ffmpeg libav ... весь текст скрыт [ показать] Ваш комментарий
Read more |