Forgot your password?
typodupeerror
Security Software

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

Posted by timothy
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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • Re:Kernel bloat (Score:5, Insightful)

    by Tapewolf (1639955) on Saturday June 28, 2014 @04:13PM (#47341829)

    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.

  • Re:Kernel bloat (Score:3, Insightful)

    by rubycodez (864176) on Saturday June 28, 2014 @04:16PM (#47341847)

    you're confused, this fights bloat on disk by letting kernel image be half the size and loading twice as fast (uncompression time is negligible, less than tenth of a second on a typical desktop)

    it of course has many other uses but you can read the article to find out

  • Re:Safe Buffer? (Score:3, Insightful)

    by Anonymous Coward on Saturday June 28, 2014 @06:49PM (#47342487)

    Sigh. Every time someone suggests online that perhaps we should be trying to put better bounds-checking constructs into languages, someone else will flame-on and say "programmers should just well, program better!". True, yet a pipe dream at the same time -- as we see by history.

    Fact is, yes, programmers should be doing proper bounds-checking. But programmers are people, and people suck (I'm a member of both sets, so I can personally corroborate this). It's time we stopped saying over and over that "Programmers just need to stop being lazy/stupid/careless" and admit that, no matter how much we whine about it, we ARE going to keep being lazy/stupid/careless because we're human. Make languages and standard libraries with safer constructs and we might someday actually make progress on this issue.

    Ah, why am I even posting -- I said about the same thing on another site a few months ago and some basement troll decided to write a small novel describing why my mere suggestion that languages could do something to improve standard libraries and string handling, was a crime worthy of death. I'm done, it's almost retirement time for me... :p

Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and crystallography weenies. FORTRAN is for wimp engineers who wear white socks.

Working...