The OpenNET Project / Index page

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

Опасная уязвимость в реализациях LZO/LZ4, затрагивающая ядро Linux, FFmpeg, OpenVPN и другие проекты

27.06.2014 09:55

В различных реализациях алгоритмов распаковки 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.

  1. Главная ссылка к новости (http://blog.securitymouse.com/...)
Лицензия: CC-BY
Тип: Интересно / Проблемы безопасности
Короткая ссылка: https://opennet.ru/40093-lzo
Ключевые слова: lzo, lz4, security
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (69) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, бедный буратино (ok), 10:30, 27/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    libzlo2, блин

    ну теперь марсоходу точно капец

     
     
  • 2.4, Аноним (-), 11:18, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +10 +/
    > теперь марсоходу точно капец

    Марсиане взломают управляющее ПО и устроят весёлые покатушки? :)

     
     
  • 3.7, ryoken (?), 11:32, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> теперь марсоходу точно капец
    > Марсиане взломают управляющее ПО и устроят весёлые покатушки? :)

    да он вроде на Power-е?

     
     
  • 4.74, Аноним (-), 21:26, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > да он вроде на Power-е?

    Как раз самое оно для марсиан...

     
  • 4.79, Серж (??), 04:55, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Биткоины на марсоходе майнить - самое оно!
     
     
  • 5.90, Аноним (-), 11:21, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Биткоины на марсоходе майнить - самое оно!

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

     
  • 3.9, Аноним (-), 11:46, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Зачем марсианам допотопная техника дикарей?
     
     
  • 4.15, Аноним (-), 12:19, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Можно извлечь немало лулзов, показывая наивным дикарям не то что есть, а то что хочется.
     
     
  • 5.23, Аноним (-), 12:57, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так вот как он снимает сам себя! А то пишут - склейка из нескольких фото...
     
     
  • 6.45, Аноним (-), 15:21, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > склейка из нескольких фото...

    Так не врут же. Они просто постеснялись уточнить где именно произведена склейка. Ну не могут же они сообщить руководству что марсоход давно расхакали местные аборигены, извлекающие уйму лулзов?

     
  • 2.38, Аноним (-), 15:06, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > libzlo2, блин

    Или Liblolz2, смотря с какой стороны посмотреть :P.

     

  • 1.3, Ordu (ok), 10:40, 27/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ждём юбилейного пятидесятилетнего бага. Двадцатилетний уже находили, если память мне не изменяет.
     
     
  • 2.6, Штунц (?), 11:26, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не думаю, что из 1965го года хоть что то дошло.
    Язык Си, к примеру, только в 1969 разрабатывать начали.
     
     
  • 3.8, Ordu (ok), 11:34, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Именно потому, что ничего из '65 ничего не дошло, мы и ждём до сих пор, когда какой-нибудь из дошедших багов успеет состарится в достаточной мере, прежде чем быть обрануженным.
     
  • 3.10, жабабыдлокодер (ok), 11:47, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вот потому и нет багов 65 года, что Си начали разрабатывать в 69-м.
     
     
     
    Часть нити удалена модератором

  • 5.68, Аноним (-), 18:33, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И что такого страшного в Lisp который лет на 10 старше C?
     
     
  • 6.85, Аноним (-), 09:09, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И что такого страшного в Lisp который лет на 10 старше C?

    Туева хуча совершенно одинаковых скобочек на все случаи жизни. Разновидностей скобок, блин, людям не хватило. На все один ответ ответ )))))).

     
  • 3.11, Штунц (?), 11:52, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Единственно, думаю, в какой-нибудь FORTRAN-библиотеке, написанной на FORTRAN'e, возможно и остались математические баги.
     
     
  • 4.52, жабабыдлокодер (ok), 16:06, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В программе на классическом фортране нет и не может быть багов. Только ошибки в реализации алгоритмов.
     
     
  • 5.58, Аноним (-), 17:07, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > В программе на классическом фортране нет и не может быть багов. Только
    > ошибки в реализации алгоритмов.

    дЫк - "особенности реализации" же, какие такие ашипки? :)

     
  • 5.86, Аноним (-), 09:12, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > нет и не может быть багов.

    Очень смелое и очень некомпетентное заявление.

    > Только ошибки в реализации алгоритмов.

    А это, типа, не баги? Вообще-то баг == ошибка.

     
  • 5.95, Аноним (-), 14:26, 29/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    программа — частный случай реализации
     
  • 3.53, rob pike (?), 16:35, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В названии "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.

     
     
  • 4.84, Аноним (-), 09:06, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В названии "ALGOL 60" ничего не просматривается?

    Вижу динозавров! :)

     
  • 2.17, Аноним (-), 12:24, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А в закрытом скорее всего так бы и не нашли.
     
     
  • 3.19, Нанобот (ok), 12:28, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    возможно. но это не ответ на поставленный вопрос.
     
     
  • 4.21, Аноним (-), 12:31, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > но это не ответ на поставленный вопрос.

    Это почему же? Знавал тут одних. Починили возможность рекурсивного сноса всех файлов по иерархии. И в ченжлог даже не пикнули. Ну да, это вам не bumblebee, где честно признались в обсираке. Разумеется, проприетарь...

     
  • 2.18, Аноним (-), 12:27, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да, какой-нибудь MS просто починит тихой сапой и вообще CVE не выпустит.

    Впрочем, чтобы что-то чинить - надо чтобы было что чинить, для начала. Покажи среди проприетари сколь-нибудь сравнимые алгоритмы? Они где???

     
     
  • 3.56, Штунц (?), 17:05, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    RAR ?
     
     
  • 4.65, Аноним (-), 17:21, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > RAR ?

    Ни разу не видел сообщений что они починили уязвимость. Хотя при сложности формата и алгоритмов как у них - там запросто может чего-нибудь накопаться. Но т.к. бабло побеждает зло, а оно шароварь - скорее всего починят тихой сапой, чтобы репутацию не портить. Кто ж будет покупать бажные программы? :)

     
     
  • 5.80, arisu (ok), 05:29, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Хотя при сложности
    > формата и алгоритмов как у них - там запросто может чего-нибудь
    > накопаться.

    особенно если учесть, например, что там есть няшная VM. теоретически, конечно, она работает в своей песочнице… но.

     
     
  • 6.83, Аноним (-), 09:04, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > особенно если учесть, например, что там есть няшная VM.

    А что она там выполняет?

     
     
  • 7.87, arisu (ok), 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

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

     
     
  • 8.91, Аноним (-), 12:22, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ухтыб ВНЕЗАПНО Спасибо, ценно Я как-то всегда считал что архиватору достато... текст свёрнут, показать
     
     
  • 9.92, arisu (ok), 18:27, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    хм я как-то даже не задумывался в эту сторону спасибо, учту и покопаю ... текст свёрнут, показать
     
  • 9.93, arisu (ok), 18:30, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    так это mp4, что ли, или какой-то из них, или прототип 8212 тоже ведь имел в... текст свёрнут, показать
     
     
  • 10.96, Аноним (-), 01:10, 01/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то не припоминаю VM в mp4 Я правда мпеги изучал в основном на примере mpeg1... текст свёрнут, показать
     
     
  • 11.97, arisu (ok), 01:13, 01/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    я не помню вообще, дошло ли это до стандартов, я не настоящий сварщик так, слыш... текст свёрнут, показать
     
  • 4.70, Аноним (-), 18:43, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > RAR ?

    Вы думаете в RAR уникальные алгоритмы? Они основаны на тех же самых.

     
     
  • 5.72, bugmenot (ok), 19:25, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    В WinRAR была эпичная дырень со спуфингом расширения файла.
    http://habrahabr.ru/company/dsec/blog/216785/

    Не совсем в алгоритме, скорее, в обработке дополнительного поля, которое WinRAR вставляет в архивы.

     
  • 2.24, бедный буратино (ok), 13:02, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    открытый код помог найти ДРУГИЕ ошибки. а вот найти ВСЕ ошибки он не может.
     
     
  • 3.31, Аноним (-), 14:16, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, скорость накопления ошибок всегда меньше скорости их исправления?
     
     
  • 4.39, Аноним (-), 15:08, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно, скорость накопления ошибок всегда меньше скорости их исправления?

    Раз на раз не приходится. Бывает так что чинят 2, сажают 1. А бывает и так что "починил 8 известных ошибок из 35. Теперь в проекте 49 известных ошибок...".

     
  • 2.26, Аноним (-), 13:19, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вряд ли здесь присутсвуют авторы этого CVE.
     
  • 2.29, Аноним (-), 13:55, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А где ты видишь, что он не помогает?
     
  • 2.32, Аноним (-), 14:17, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Эти студни так активны только летом?
     
     
  • 3.36, Michael Shigorin (ok), 14:50, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Эти студни так активны только летом?

    Да если б, это уже взрослые особи.

     
  • 2.34, Аноним (-), 14:41, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А тебя сильно утешит, что в проприетарщине и твоем любимом коде под лицензией BSD, который при первой возможности прикроют проприетарщики, уязвимости не найдут никогда?

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

     
     
  • 3.40, Аноним (-), 15:09, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А тебя сильно утешит, что в проприетарщине и твоем любимом коде под
    > лицензией BSD,

    ЧСХ, LZ4 - таки под BSD. И у проприетарщиков в их appliance он ничуть не менее бажный. Только в силу зажатых исходников там надеяться придется разве что на милость блобмейкера.

     
  • 2.42, тигар (ok), 15:18, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> В различных реализациях алгоритмов распаковки LZO и LZ4 выявлена опасная уязвимость (CVE-2014-4607), которая присутствует уже около 20 лет и может привести к повреждению областей памяти при распаковке специально оформленных сжатых данных.
    > Подскажите - это так помог открытый код искать ошибки?

    я был не прав в #14, они начали рефлексировать:-) мишенька в #35 вообще умничка:)

     
     
  • 3.43, Michael Shigorin (ok), 15:20, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > я был не прав в #14

    Уважаю.

     
     
  • 4.55, rob pike (?), 16:45, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    За грамотность?
     
     
  • 5.62, Аноним (-), 17:16, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > За грамотность?

    Школота никогда не скажет "я не прав". Их физиологически от этого бомбашит на части - кактузикгрелку, да :)
    Вот Майкл похоже в уме галочку и поставил что Тигар - не школота. Уже не плохо :)


    PS: Миру пис, фолкс! Дожди кончились - все на пляж!

     
     
  • 6.73, Аноним (-), 21:24, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Школота
    > физиологически
    > бомбашит
    > кактузикгрелку

    НеШкoлота на опеннете :).

     
     
  • 7.78, Аноним (-), 03:56, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это такое место бро, я бы мог о чём то высоком, но ...
    "Поручик! Тут же никто этого не оценит!" (С)
     

  • 1.13, pansa (ok), 12:12, 27/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    16mb для x86_86, для 64 число слишком велико. Ещё один повод обновить арх-ру :)  
     
     
  • 2.94, лзз (?), 00:19, 29/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    практически весь арм пока 32битный.
     

  • 1.28, Аноним (-), 13:36, 27/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Работает не трогай! Поэтому за 20 лет ни кто аудит и не делал.
     
  • 1.30, бедный буратино (ok), 13:59, 27/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    страница по openbsd к делу отношения не имеет. в портах уже давно обновили

    https://twitter.com/OpenBSD_ports/status/482303624794472448

     
     
  • 2.50, quiet (?), 15:34, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > в портах уже давно обновили

    А в пакетах обновят, как всегда, в следующем релизе - 1 ноября.

     
     
  • 3.67, бедный буратино (ok), 17:34, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А в пакетах обновят, как всегда, в следующем релизе - 1 ноября.

    да, успеет в следующий релиз. а мог бы и не успеть. :)

     
  • 3.75, Аноним (-), 21:28, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А в пакетах обновят, как всегда, в следующем релизе - 1 ноября.

    Правильно, должны же кидизы наконец получить себе бесплатный хостинг на каникулы?!

     

  • 1.33, Anton (??), 14:32, 27/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    http://fastcompression.blogspot.ru/2014/06/debunking-lz4-20-years-old-bug-myt
    судя по этому описанию уязвимость не очень опасная - нужна 32битная система и блок больше 8 Мб (обычно размер блока меньше)
     
     
  • 2.37, Michael Shigorin (ok), 14:58, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > http://fastcompression.blogspot.ru/2014/06/debunking-lz4-20-years-old-bug-myt

    Спасибо, интересный разбор характерного полёта.

    ---
    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?
    ---

     
     
  • 3.41, Аноним (-), 15:12, 27/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >  Well, because there was no real-world risk.

    Автор такой крутой - за все использования либы головой отвечает. Зато как это в CVE оформили - сразу подорвался оправдания писать. Лучше б он год назад это законопатил - тогда не пришлось бы год спустя так оправдываться. Упование на то что блок нигде и никогда не превысит 16М - это из разряда "640Кб хватит всем".

     
     
  • 4.76, Elhana (ok), 01:42, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да он ни на что не уповает, он пишет что ни в одной известной ему реализации не используется блок в 16М, по стандарту для LZ4 он 4М и т.п.... хотя судя по сообщению товарища, который поднял бучу ffmpeg/libav отличились в этом плане (удаленное выполнение кода), но они уже выпустили патч.
     
     
  • 5.81, Аноним (-), 09:01, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > по стандарту для LZ4 он 4М

    Если обратить внимание, 4M там для поточной версии. Мягко говоря, с сжатыми *потоками* работают далеко не все. Для блочного вариатна типовой блок 8Мб, но есть одно "но". Это подразумевает дефолтный формат. А те или иные апликухи, которым 8Мб оказалось мало - могут использовать свой формат и чисто технически могут скормить либе и более крупные блоки. И вот так эксплойт вполне себе сработает...

    > но они уже выпустили патч.

    Тем не менее, со стороны автора либы так делать не очень хорошо. Особенно если он целый год был в курсе такой возможности.

     
  • 5.89, Аноним (-), 11:17, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Раскладывать минное поле в таких либах - не есть правильно. Так что то что в большинстве программ оно неэксплуатируемо - это, конечно, хорошо. Но программ много разных бывает, расписываться за всю планету как-то достаточно безответственно.

    > ffmpeg/libav отличились в этом плане (удаленное выполнение кода)

    Не совсем понимаю как выглядит именно выполнение кода в том же LZO, ибо баг специфичен и дает очень ограниченные возможности манипуляции памятью. В LZ4 - там более интересно, это еще может быть.

     
  • 3.88, Аноним (-), 11:12, 28/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Спасибо, интересный разбор характерного полёта.

    Что интересно, автор снес из бложика комент, указывавший на то что ffmpeg/libav вполне могут пострадать из-за дырки. Видимо неудобно ему замечать такие вещи. Вот те раз - подумал Штирлиц. Зачетный демарш...

     

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



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

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