Slashdot Mirror
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.
Yes.
Without question.
I will personally bet a Bitcoin that there will be client products affected within a week. Oberhumer, you willing to take my bet? Is anyone else? Watching these idiots line up to say this isn't exploitable is giving me deja vu for GOBBLES back in the day.
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.
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.
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
So it can uncompress itself? Or so it can uncompress the initial ram disk?
More importantly what is sais?
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
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
but NSA knows.
Decompressing initramfs images? Stuff like that is great for embedded systems. The feature is optional.
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.
Why should the Linux kernel have a compression algorithm in it?
Because it aspires to compress itself into a microkernel.
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.
Jumpstart the tartan drive.
Whoosh! I think O
I wrote my own GIF codec 20 years ago, the whole algorithm could fit on two screen pages.
Three words: goto considered harmful. Safe code isn't only about the ability to make it safe. It's about a set of rules the environment or language imposes on the programmer to make it *easier* to make it safe and *harder* to make it unsafe. The programmer can still choose the language, so it's a self-imposed set of rules. Like garbage collection. Of course any decent programmer can do his own garbage collection. But if you can keep the programmer from having to do that, you (1) free him up to do things that still actually require his intellect and (2) eliminate or at least greatly reduce the probability that he will inadvertently introduce errors. You can make unsafe code go away by teaching good programming habits. That's why we don't see many goto lines in C code any more. But the biggest change comes from making it harder to write unsafe code than it is to write safe code.
Because it can.
Serious. That's why.
Do you actually know about this specific feature of the kernel, or are you just trying to appear cynical and wisened?
One suspects it's there because it's actually used by something. One also suspects it's used for a reason.
A cynical man would say that none of those four things you listed are not that important. :) I think only "compressed init filesystem" is widely used in PCs, and we would have enough space to leave it uncompressed too.
Do you actually know about this specific feature of the kernel, or are you just trying to appear cynical and wisened?
Yes, my friend, I can confirm that I actually know something about it. I have browsed through the kernel compression algorithms because it is part of my job. It seems that leaving out a lot of that stuff would leave us with a leaner and nicer kernel. A lot of the compression stuff there is just because Linux has to have "everything".
One suspects it's there because it's actually used by something. One also suspects it's used for a reason.
I doubt if you even know what kind of things it is used for.
Are you sure you understand what a microkernel design actually is?
The area of your brain which processes humor. ;)
32bit OS / 32bit app or 32bit cpu
Hell, I even saw a very specific type of corruption that instantly crashed NTFS VxD's upon mounting/booting. You'd attach the drive and... poof goes your OS to BSOD. Disconnect and reboot and everything fine again but maybe you get ChkDsk running. I had to mount it in the recovery console with the NTFS driver renamed to run ChkDsk on it. It worked from then on. Don't even try to tell me that it wasn't because of a poorly handled pointer causing the program to get overwritten with garbage. Probably some sign conversion nonsense.
I have yet to see Microsoft admit that this is a problem. It's like the old Autorun exploit but more subtle. I'm not even sure you could get it to run arbitrary code but I'm sure one of the readers will figure it out some day. :/
How could you think switching c++ would solve any issues knowing a translator for the programming language g van be compiled in c, the old Rusan joke about the garagekey. Your antivirus has no chance when it comes to a pay load being in g that then gets translated back to c because it has already exsepted it in the door to asymbly line (native language) slick key that garagekey
I haven't seen a linux kernel from a distro that used LZO as the default compression algorithm.
Bloat isn't just the size on stable storage... In fact most of the problems of software bloat are entirely separated from that metric, code size, complexity and other effects are far greater.
It seems that leaving out a lot of that stuff would leave us with a leaner and nicer kernel. A lot of the compression stuff there is just because Linux has to have "everything".
Look like those in charge disagree, and presumably they have their reasons. There are downsides to being lean-and-mean, of course.
I doubt if you even know what kind of things it is used for.
You're right.
And a cynical reponse would be "if you are that fearful, then rebuild the kernel. you have the source"
wtf is wrong with people?
Seems the bug also affects the writer's spell-checking utility.
this compression code is very tiny in the binaries. most of the kernel is device drivers
I take such news with a grain of salt. In my experience/estimates, about 80% of security experts report "not possible to reproduce/impossible to exploit" for REAL exploitable bugs.