

Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right - nkurz
http://blog.securitymouse.com/2014/06/understanding-lz4-memory-corruption.html

======
emn13
This article sounds bunk. The argument boils down to "because a security flaw
is theoretically possible, we should consider it to be practically critical".

Obviously, that's nonsense. Assuming other analysis is correct suggesting that
no vulnerable applications could be found, then there is no security flaw. LZ4
is not exploitable by itself; it is not a standalone application. Clearly,
there's a bug. It's nice that it's fixed because it might have caused nasty
problems in the future.

By analogy; is C a security flaw because it is not memory safe? Clearly, usage
of C can result in overflows and other memory corruption. Nevertheless, usage
of C does not necessarily imply security flaws. It's nice (and important in
the long run) that we can avoid certain risks by fixing bugs or design flaws
in our tools, and many other languages attempt to by being (mostly) memory
safe to avoid this class of risk. But, however important, that long-term
improvement is not the same thing as a critical security flaw now.

------
Tractor4973
The LZ4 Memory corruption was already fully described at the LZ4 issue board,
and accepted by the LZ4 author. What is this article supposed to learn us ?

~~~
Tractor4973
btw : [http://fastcompression.blogspot.fr/2014/06/lets-move-
on.html](http://fastcompression.blogspot.fr/2014/06/lets-move-on.html)

------
nkurz

      It's Just Not Big Enough
      The claim that 64bit platforms are not exploitable is 
      incorrect. This is the same mindset that created today's 
      LZO/LZ4 vulnerability. "No one will ever have that much 
      RAM to cause a 32bit integer overflow!". Well, today we 
      do. If this bug would have persisted and propagated 
      further, surely 64bit architectures would be effected in 
      the not-so-near future. 
    

Worrying that RAM sizes will exceed 64-bit addressability hasn't been one of
my worries. 2^64 is about 70,000 Petabytes. Of course, it wasn't too long ago
when a Petabyte seemed unattainable, and not too long before that that a
Gigabyte seemed giant, and even a Megabyte once seemed almost limitless. Am I
just being short sighted?

~~~
Tractor4973
Of course, this argument is totally nuts. 2^64 of RAM is not accessible,
period. It's ludicrous to pretend that a code delivered today should take into
consideration a potential issue that might happen in 30 years from now.
Frankly, you expect the code to no longer be updated that long and still be
used ??

~~~
OMGWTF
Well, if a fix is possible without much hassle, it should be implemented. But
it's crazy to raise as much attention as in this case.

------
chris_wot
Ok, it appears there is a possible overflow in the Linux LZ4 decompression
routine... But what actually uses this in the Linux kernel? Not saying it
shouldn't be addressed, but is this really critical as it currently stands? It
doesn't look like there is any way to _currently_ use this vulnerability.

~~~
Tractor4973
Current kernel users : zRam, SquashFS, BTRFS, BootLoader First 3 use small
block sizes, KB range. Last one used the LZ4 file format, which limits blocks
to 8 MB.

Yes, there is no kernel program at risk right now, but it's nonetheless good
to plug the vulnerability, in anticipation for future usages.

In my view, this does not deserve headlines. Instead, we should be happy to
have software coders fixing problems even before they get a chance to happen.

------
OMGWTF
I think the point of his critics wasn't that this is no real vulnerability but
that the implied severity was blown out of proportion.

------
tptacek
I'm a little confused. Did Bailey find this bug, or did Ludwig Strigeus?

~~~
templeton39
Ludwig did :
[https://code.google.com/p/lz4/issues/detail?id=52&can=1](https://code.google.com/p/lz4/issues/detail?id=52&can=1)
Bailey then misappropriate the finding, pretending to have done all analysis,
which was all readable and accessible for everybody within this thread.

~~~
tptacek
Do you have firsthand knowledge of this? Does that include all the various
places the bug exists? Bailey documented more than one bug.

I read the bug report and the angry blog post about it, too.

~~~
Tractor4973
Yeah, it could be that both discovered the vulnerability independently. It's
just that, from a timing perspective, Ludwig found it first, and provided
explanations which where accessible and readable to all on the public board.
It doesn't necessarily mean that Bailey read them and appropriate them.

