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

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.

Comments

Re: Kernel bloat

[coliverhb]

Are you trolling?

There are many good use cases - as is illustrated in TFA

Configure your kernel and rebuild if you don't want the benefits.

Re:Kernel bloat

[Tapewolf]

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

[BitZtream]

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.

Re:Kernel bloat

[rubycodez]

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

Famous last words

[93 Escort Wagon]

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.

Re:Famous last words

[russotto]

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)

If a tree falls in a forest...

[Sits]

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.

Re:Kernel bloat

[marciot]

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

Because it aspires to compress itself into a microkernel.

Safe Buffer?

[Midnight Thunder]

Given the number of security issues related to buffer over-runs, I wonder whether C/C++ should provide a safe buffer that would help alleviate these issues? Sure it might compromise performance slightly, though it might be acceptable when faced with the alternative of unexpected issues due to an unforeseen buffer overrun.

Re:Safe Buffer?

[Anonymous Coward]

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

Re:Safe Buffer?

[fnj]

I wonder whether C/C++ should provide a safe buffer

When I see that expression "C/C++" used in this particular context it raises my hackles, because it indicates the writer does not understand the difference.

In C the programmer is free to USE a buffer safely, by doing his own bounds checking. In C++ the programmer is free to use C++'s non-overflowing dynamically-allocated/self-growing constructs, as well as a simple C style array or fixed-size-allocated buffer. C++ makes it substantially easier to use a buffer safely, but you can do it in C also, by exercising more intricate care in programming.

In principle you could greatly increase reliability/security by switching the ecosystem from C to C++ and enforcing certain rules, but I am afraid that the base of truly competent C++ programmers is at least an order of magnitude less than that of C programmers, and worse, programmers who can write C++ and get it to compile, but are not truly proficient and competent in C++, seldom realize their own deficiency.

TL;DR: C++ *HAS* safe buffers if you choose to use them.

Re:Safe Buffer?

[leuk_he]

Why still program in C? Simple: C is easy to glue to everything, just because it assumes not too much about the data structures. And because you have reinvent data validation ( safe buffers) for every interface again, there is a huge risk there.

The obvious solution is to use proven libraries for these problems (opensll, libzzo ;) . However if one of these libraries has a bug, (or is not obvious to use) the problem is in many programs at once.

Re:Kernel bloat

[Anonymous Coward]

Are you sure you understand what a microkernel design actually is?

The area of your brain which processes humor. ;)

Re:You don't know...

[amorsen]

File system drivers in general are not properly security vetted. You can do interesting stuff to a Linux box if you put ext4 on a fake device and start messing with what is on the disk while it is being read. Many device drivers have similar problems; you could find a Linux device driver with a problem and make a fake piece of hardware resembling the real thing while exploiting the bug.

This is pretty much unfixable. While most core OS code is of a high quality these days, there is just too much driver code around. A proper audit is infeasible.

Besides, Thunderbolt makes it pointless. With Thunderbolt, you do not need to exploit anything, the bus provides you with unlimited access.

It is a sad state of affairs really.

Re:Kernel bloat

[rubycodez]

this compression code is very tiny in the binaries. most of the kernel is device drivers