И правда, решето.

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

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

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

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

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

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

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

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

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

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

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

Апдейты уже выкатили? Если да, то в какие дистры?

Апдейты?

В арч пришло

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

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

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

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

Решето - это если бы не обнаружили.

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

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

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

у нас арм уже все 64-х битные?

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

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

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

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

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

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

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

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

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

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.

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

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

наверняка АНБ знало и пользовалось :)

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

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

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

А что в этом плохого? В конечном счете качество софта от этого только выиграет.

первый раз слышу про LZO. оно вообще хоть где-то используется кроме ZFS?

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

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

которые

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

один из вариантов упаковки ядра

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

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

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

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

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

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

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

Go реально так хорош? Столько уже на нем написали.

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

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

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

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

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

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

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

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

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

openvpn

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

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

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

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

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

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

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

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

Go реально так хорош?

Не верь никому на слово, оцени сам. Благо изучать там не так уж и много.