Results 1 to 8 of 8

Thread: Another LZ4 Security Issue Analyzed

  1. #1
    Join Date
    Jan 2007
    Posts
    15,438

    Default Another LZ4 Security Issue Analyzed

    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

  2. #2
    Join Date
    Dec 2012
    Posts
    459

    Default

    Hope they fix the kernel version as well...

  3. #3
    Join Date
    Jan 2012
    Posts
    9

    Default

    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.

  4. #4
    Join Date
    Jul 2014
    Posts
    26

    Default

    Quote Originally Posted by Rexilion View Post
    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.

  5. #5
    Join Date
    Jul 2014
    Posts
    26

    Default

    Quote Originally Posted by evergreen View Post
    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.

  6. #6
    Join Date
    Jun 2012
    Posts
    328

    Default

    Quote Originally Posted by evergreen View Post
    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.

  7. #7
    Join Date
    Apr 2008
    Posts
    182

    Default

    Quote Originally Posted by phoronix View Post
    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!

  8. #8
    Join Date
    Aug 2013
    Posts
    81

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •