Live data from Hacker News

Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right

blog.securitymouse.com

1–10 of 14 posts

Re: Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right

#3

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 ?

btw : http://fastcompression.blogspot.fr/2014/06/lets-move-on.html

Re: Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right

#4
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.

Re: Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right

#5
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.

Re: Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right

#8

  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?

Re: Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right

#9
post #8

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

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

Re: Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right

#10
post #7

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

Ludwig did : 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.
Post reply on HN