Slashdot Mirror

← Back to Stories (view on slashdot.org)

Are the Hard-to-Exploit Bugs In LZO Compression Algorithm Just Hype?

Posted by timothy on from the you'll-never-feel-it dept.

NotInHere (3654617) writes In 1996, Markus F. X. J. Oberhumer wrote an implementation of the Lempel–Ziv compression, which is used in various places like the Linux kernel, libav, openVPN, and the Curiosity rover. As security researchers have found out, the code contained integer overflow and buffer overrun vulnerabilities, in the part of the code that was responsible for processing uncompressed parts of the data. Those vulnerabilities are, however, very hard to exploit, and their scope is dependent on the actual implementation. According to Oberhumer, the problem only affects 32-bit systems. "I personally do not know about any client program that actually is affected", Oberhumer sais, calling the news about the possible security issue a media hype.

6 of 65 comments (clear)

  1. Re:Kernel bloat by Tapewolf · · Score: 4, Insightful

    Why should the Linux kernel have a compression algorithm in it?

    Because it needs to compress and decompress things.

    The kernel image is usually compressed anyway, then you've got things like page compression for zram, in-filesystem compression support - heck, BTRFS uses LZO! I think some network layer stuff like PPP supports header compression, and all that's only the things I'm vaguely aware of.

  2. Re:Kernel bloat by BitZtream · · Score: 5, Informative

    Compressed memory? Filesystem compression? Compressed memory before swap? Compressed init filesystem?

    Lots of valid reasons. Those are just the ones that I know of off the top of my head and I don't even use Linux.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  3. Famous last words by 93+Escort+Wagon · · Score: 5, Informative

    I'm old enough to recall when many people argued we didn't have to worry about various (then theoretical) JPEG vulnerabilities because they would be "extremely hard to exploit". But once it becomes known that something is possible, people have repeatedly proven themselves extremely clever in figuring out how to accomplish it.

    If I was on the Rover team, I might not worry - but terrestrial users of LZO compression should at least start thinking about how to ameliorate this.

    --
    #DeleteChrome
    1. Re:Famous last words by russotto · · Score: 5, Interesting

      In this case, it's not just "extremely hard to exploit" (which means the NSA had it done 10 years ago and the other black hats 5). It appears that it's impossible -- to cause the overrun requires an compressed block size larger than the affected programs will accept. (of course, this doesn't preclude the possibility of other bugs which allow a larger compressed block through)

  4. If a tree falls in a forest... by Sits · · Score: 4, Informative

    Whether you consider this issue is hype depends on your answer to "if a tree falls in a forest and there's no one to observe it..." thought experiment.

    The author of LZ4 has a summary with regards to LZ4 (both LZO and LZ4 are based on the LZ77 compression and both contained the same flaw) - that the issue has not been demonstrated as being exploitable in currently deployed programs due to their configuration (a rather angrier redacted original reply was originally posted). So at present this issue is severe but of low importance. If a way is found to exploit this problem on currently deployed popular programs without changing their configuration then this issue will also be of high importance but since this issue has now been patched hopefully newly deployed systems wouldn't be vulnerable.

  5. Re:Kernel bloat by marciot · · Score: 4, Funny

    Why should the Linux kernel have a compression algorithm in it?

    Because it aspires to compress itself into a microkernel.