LINUX.ORG.RU

Найдена опасная уязвимость в алгоритмах распаковки LZO и LZ4

 , ,


0

6

В алгоритмах распаковки LZO и LZ4 найдена очень опасная уязвимость (CVE-2014-4607), которая существует более 20 лет. Эта уязвимость может повредить определенные области памяти при распаковке специально созданных сжатых данных. Проблема существует из-за целочисленного переполнения,которые возникают при при распаковке блоков нулевых байтов свыше 16Мб.

В данное время существует возможность применения уязвимости в LZO для совершения DoS-атак и выполнения определенного вредноносного кода.

Алгоритмы LZO и LZ4 широко используются в программном обеспечении: от ядра Linux до различных встраиваемых решений.

Уязвимость подвержены все пакеты lzo1, lz4 и liblzo2 в в дистрибутивах GNU/Linux и иные реализации lzo и lz4, использующиеся в других продуктах.

>>> Подробности

★★★★★

Проверено: DoctorSinus ()
Последнее исправление: DoctorSinus (всего исправлений: 1)

очень опасная уязвимость (CVE-2014-4607), которая существует более 20 лет

Кто-нибудь кого-нибудь уязвил за эти 20 лет этой уязвимостью?

anonymous
()

уязвимость в алгоритмах распаковки
более 20 лет

Плохо, очень плохо... O_o

qzxcvbnm
()

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

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

Однако, к счастью, проявляется она везде по-разному. Данные для атаки надо отдельно конструировать для конкретной атакуемой релизации.

P.S.Вот поэтому в современные языки программирования встраивают защиту от манипуляци с произвольными регионами памяти. А в некоторые ещё и защиту от overflow.

P.P.S.Интересно, что будет с реализацией go-lz4.

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 1)
Ответ на: комментарий от proud_anon

Вот поэтому в современные языки программирования встраивают защиту от манипуляци с произвольными регионами памяти. А в некоторые ещё и защиту от overflow.

Более того, её встраивают даже в ядра и процессоры, но это не повод забивать на безопасность.

Reinar
()

Математические алгоритмы или наиболее частая реализация?

Quasar ★★★★★
()
Ответ на: комментарий от Quasar

Автор новости безграмотный

А проверяльщик?

anonymous
()
Ответ на: комментарий от anonymous

A first minor one is : it is necessary to work within a 32-bits environment. 64-bits is totally unaffected.

На этом можно и закончить историю о страшной и повсеместной уязвимости.

anonymous
()
Ответ на: комментарий от anonymous

К тому же, для эксплуатации уязвимости необходимо сжатие с блоками размером не менее 16 мегабайт. Но такой размер блока практически нигде и никем не используется.

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

anonymous
()
Ответ на: комментарий от anonymous

автор lz4 уже устал это все обсуждать: http://fastcompression.blogspot.com/2014/06/debunking-lz4-20-years-old-bug-my... (англ.) Вкратце, практические атаки невозможны.

ну то есть — давайте это просто будем называть багом, а не уязвимостью.

просто — баг с низкой вероятностью воспроизведения (или не низкою?)

но всё равно баги нужно исправлять.. даже если они не являются уязвимостями

user_id_68054 ★★★★★
()
Последнее исправление: user_id_68054 (всего исправлений: 1)
Ответ на: комментарий от int13h

Серверный сегмент это практически полностью выводит из-под удара. Кроме серверов на арме, разве что, но это пока такая редкость...

anonymous
()

обожемой, пойду поем

anonymous
()
Ответ на: комментарий от user_id_68054

баг с низкой вероятностью воспроизведения (или не низкою?)

To be exposed to this risk, very large blocks of 16MB or larger must be read by the decoder. Let's have a look at several high-profile programs using LZ4. ZFS ? Max block size is 128 KB. Lucene ? Typical index size is 16 KB. It could be a bit more, say 64 KB, that's still far short of the objective. zram maybe ? nope, 4 KB memory segments. Linux kernel ? The boot section has to decompress a multi-megabytes kernel into memory, surely it can match the limit ? Yes, it does, but it uses the LZ4 Legacy File format, which limits each block to 8 MB maximum. OK, maybe AAA games such as Guild Wars 2 ? nope, real-time protocol is the realm of short messages, the protocol itself doesn't allow anything beyond a few KB. And so on, and on.

anonymous
()
Ответ на: комментарий от anonymous

ну ок, ок :-) .. под низкой вероятностью будем подразумевать --- ...

... --- низкую вероятность существования такого места (такой программы\утилиты) где этот баг мог бы быть воспроизведён :-)

user_id_68054 ★★★★★
()
Ответ на: комментарий от int13h

[irony]на arm только lzo в промышленных масштабах перепаковывать.[/irony]

bl ★★★
()

в этом году, я вижу, мода на пересмотр и поиск уязвимостей в открытом софте

что сказать... ШЕРЕТО!

reprimand ★★★★★
()

Проблема существует из-за целочисленного переполнения,которые возникают

из-за переполнения

которые

Не согласуется по числу

upcFrost ★★★★★
()
Ответ на: комментарий от anonymous

Кто-нибудь кого-нибудь уязвил за эти 20 лет этой уязвимостью?

Самолюбие авторов lzo.

ncrmnt ★★★★★
()
Ответ на: комментарий от anonymous

Кто-нибудь кого-нибудь уязвил за эти 20 лет этой уязвимостью?

Взрывом были уязвлены анусы авторов алгоритмов.

bluesman
()
Ответ на: комментарий от int13h

Нет, allwinner ещё даже A9X не выпустили. И я не уверен, что будет нормальное SDK.

mittorn ★★★★★
()
Ответ на: комментарий от RiseOfDeath

да я и не говорю, что плохо
просто до этого никто особо этим не занимался

reprimand ★★★★★
()

Как будто в zlib таких не было... А еще всякие «zip-bombs» из лихих 90-х вспоминаются, звук модема, BBS, FIDO... Эх как меня понесло...

Rolex ★★
()
Ответ на: комментарий от Valdor

Багу 20 лет, какова вероятность что в там еще несколько таких же? Поэтому и решето.

loz ★★★★★
()

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

matumba ★★★★★
()
Ответ на: комментарий от matumba

Странно, что его имя не публикуют

Понятное дело, человек матумбы испугалсо.

anonymous
()

Ого! Похоже эта уязвимость будет таким термоядерным апокалипсисом, что Heartbleed цветочками покажется.

Deleted
()
Ответ на: комментарий от Deleted

Ну-ну, уязви меня, термоядерный апокалипсун ты наш.

anonymous
()
Ответ на: комментарий от Deleted

Никакой heartbleed не сравнится с триллионами убытков от проприетарщины. Гейтс скоро станет триллионером.

anonymous
()
Ответ на: комментарий от proud_anon

P.S.Вот поэтому в современные языки программирования встраивают защиту от манипуляци с произвольными регионами памяти. А в некоторые ещё и защиту от overflow.

А правда что в некоторых типах процессоров страницу памяти можно отметить как «только данные» и тогда при переходе выполнения на неё случиться соответствующее прерывание?

rezedent12 ☆☆☆
()

а в винде этой уязвимости нет?

anonymous
()
Ответ на: комментарий от Reset

Уверен, что да.

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

Odalist ★★★★★
()
Ответ на: комментарий от Odalist

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

Reset ★★★★★
()

Такая опасная, что узнали о ней спустя 20 лет, ок.

amazpyel ★★★
()

Неуловимый Джо найден спустя двадцать лет!

Какие тайны скрывал от нас ловкий ковбой?

buddhist ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.