Another LZ4 Security Issue Analyzed

[phoronix]

Phoronix: Another LZ4 Security Issue Analyzed

At the end of June I mentioned LZO and LZ4 security issues were uncovered while coming to light in the past week was another potential LZ4 security vulnerability for the lossless data compression library...

http://www.phoronix.com/vr.php?view=MTc0MTE

[Rexilion]

Hope they fix the kernel version as well...

[evergreen]

It's not "another LZ4 security issue", as far as I understand,
it's the same one, but has been, as 0xBADC0DE said, more thoroughly analyzed.
And as a consequence, the same fix applies.
Yes, the linux Kernel implementation has also been patched the same way.

The conclusion is nonetheless valid :
even though the issue requires very large data blocks which are likely out of most program specs,
the fix is nonetheless recommended for all 32-bits applications, just for simplicity.

[rob11311]

Hope they fix the kernel version as well...

Something like gkh Stable Kernel announcement - lz4: add overrun checks to lz4_uncompress_unknownoutputsize() Linux 3.15.4 - Sun, 6 Jul 2014 19:09:39 -0700 ?

Original blog on 1st, so I expect they have covered it already.

[rob11311]

It's not "another LZ4 security issue",
..
even though the issue requires very large data blocks which are likely out of most program specs,
the fix is nonetheless recommended for all 32-bits applications, just for simplicity.

Sure? From new analysis relating to 32bit ARM :

2,598,823 bytes of the value 0xff, plus one final byte of 0xa7 are required to generate the exact 'length' value of 0x27800000. When this 'length' value is added to an 'op' address of 0xd8800000, what do we get? We get nothing. That's right, the address zero.

The overflow checks seem mandatory, not just a belt & braces precaution.

[0xBADCODE]

And as a consequence, the same fix applies.

The problem seems to have same nature: 32-bit signed integer overflow, causing wrap-around and as the result, some potentially harmful memory accesses. However, this seems to be another instance of problem - this commit has only landed recently and it has been separate thing, issues mentioned in first announce were addressed in earlier coomits. That's how I learned there was some trouble on the way - I detected new commit and took a look around, getting curious about cause. It turned out it has been another security fix.

[DrYak]

At the end of June I mentioned LZO and LZ4 security issues were uncovered

While it's very good that LZ4 gets investigated for vulnerabilities (the less bugs, the better), we must not panic: the potential attack surface for this kind of bugs is rather low.

LZ4 is *not* used on the web (low porforming compression). LZ4 is more used for fast loading from mass media (crazy high compression/decompression speeds).
Thus, most of the data that feeds into LZ4 isn't coming from unknown 3rd party sources, most of the time data fed into lz4 decompressor is data that the owner has previously compressed into lz4 him/her self.

A bug into the defalate algorithme (used by a bazillion of things on the net) would have been much more dramatic.

But, still, the bug hunting is welcome!

[chinoto]

Ah, I love the smell of fresh FOSS in the morning... oh wait, this was half a month ago, I need to catch up O_O
But seriously, a relatively small problem that could have just been ignored, was fixed because that's how well this model works