Understanding the LZ4 Memory Corruption Vulnerability: You Don't Play Right • Hacker News Board

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

#11

Post by Tractor4973 » Sat, Jun 28, 2014, 6:04 PM UTC

chris_wot wrote: post #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.

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.

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

#12

Post by OMGWTF » Sat, Jun 28, 2014, 7:25 PM UTC

Tractor4973 wrote: post #9

nkurz wrote: 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 ??

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.

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

#13

Post by tptacek » Sat, Jun 28, 2014, 7:27 PM UTC

templeton39 wrote: post #10

tptacek wrote: 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.

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.

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

#14

Post by Tractor4973 » Sat, Jun 28, 2014, 10:43 PM UTC

tptacek wrote: post #13

templeton39 wrote: post #10

Earlier quoted context omitted.

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.

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.

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.