Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

timothy posted about 3 months ago | from the you'll-never-feel-it dept.

Security 65

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.

cancel ×

65 comments

Sorry! There are no comments related to the filter you selected.

Absolutely. (1)

Anonymous Coward | about 3 months ago | (#47341739)

Yes.

Unquestionably. (0)

Anonymous Coward | about 3 months ago | (#47341795)

Without question.

Re:Absolutely. (0)

Anonymous Coward | about 3 months ago | (#47341903)

+1 informative

Kernel bloat (-1, Flamebait)

Animats (122034) | about 3 months ago | (#47341793)

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

Re: Kernel bloat (2)

coliverhb (886806) | about 3 months ago | (#47341817)

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 (-1)

Anonymous Coward | about 3 months ago | (#47341823)

So Linus can shit it out his tiny sphincter.

Re:Kernel bloat (4, Insightful)

Tapewolf (1639955) | about 3 months ago | (#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 (5, Informative)

BitZtream (692029) | about 3 months ago | (#47341831)

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 (1)

jones_supa (887896) | about 3 months ago | (#47343201)

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.

Re:Kernel bloat (0)

Anonymous Coward | about 3 months ago | (#47343951)

I haven't seen a linux kernel from a distro that used LZO as the default compression algorithm.

Re:Kernel bloat (0)

Anonymous Coward | about 3 months ago | (#47344547)

And a cynical reponse would be "if you are that fearful, then rebuild the kernel. you have the source"

wtf is wrong with people?

Re:Kernel bloat (-1)

Anonymous Coward | about 3 months ago | (#47341833)

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

Because it can.

Serious. That's why.

Coders approach all problems by writing more code. Making sense in some overall design is irrelevant.

Re:Kernel bloat (-1)

Anonymous Coward | about 3 months ago | (#47342075)

Why is this modded down? It neatly explains the last 30 years of software design (it ain't engineering). All thanks to the one technology we've improved radically: making smaller transistors.

No other technology has progressed at the same rate. None. You don't see 747s with 45 engines all pointing in different directions because "it can", because it can't!

Re:Kernel bloat (1)

Wootery (1087023) | about 3 months ago | (#47342653)

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.

Re:Kernel bloat (0)

Anonymous Coward | about 3 months ago | (#47343219)

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.

Re:Kernel bloat (1)

Wootery (1087023) | about 3 months ago | (#47344229)

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.

Re:Kernel bloat (0)

Anonymous Coward | about 3 months ago | (#47341835)

So it can uncompress itself? Or so it can uncompress the initial ram disk?
More importantly what is sais?

Re:Kernel bloat (3, Insightful)

rubycodez (864176) | about 3 months ago | (#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:Kernel bloat (1)

Megol (3135005) | about 3 months ago | (#47344067)

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.

Re:Kernel bloat (2)

rubycodez (864176) | about 3 months ago | (#47344601)

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

Re:Kernel bloat (1)

epyT-R (613989) | about 3 months ago | (#47341937)

Decompressing initramfs images? Stuff like that is great for embedded systems. The feature is optional.

Re:Kernel bloat (4, Funny)

marciot (598356) | about 3 months ago | (#47342241)

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

Because it aspires to compress itself into a microkernel.

Re:Kernel bloat (-1)

mishehu (712452) | about 3 months ago | (#47342345)

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

Re:Kernel bloat (1)

Anonymous Coward | about 3 months ago | (#47342469)

Whoosh! I think O

Re:Kernel bloat (2, Funny)

Anonymous Coward | about 3 months ago | (#47343239)

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

The area of your brain which processes humor. ;)

Skin in the game. (2)

weevlos (766887) | about 3 months ago | (#47341805)

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.

Re:Skin in the game. (-1)

Anonymous Coward | about 3 months ago | (#47341905)

Fuck you, Weev.

Re:Skin in the game. (-1)

Anonymous Coward | about 3 months ago | (#47341919)

How much will the bitcoin be worth in a week?

Re:Skin in the game. (1)

weevlos (766887) | about 3 months ago | (#47341971)

That's a great question, best buy it when you make the bet to hedge the risk.

Famous last words (5, Informative)

93 Escort Wagon (326346) | about 3 months ago | (#47341871)

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 (5, Interesting)

russotto (537200) | about 3 months ago | (#47342391)

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)

Re:Famous last words (-1)

Anonymous Coward | about 3 months ago | (#47343125)

All your Rovers are belong to us.

Let them hack the rover. and good point, worry about it if you are terrestrial.

You don't know... (1)

abrahamOH (3712519) | about 3 months ago | (#47341935)

but NSA knows.

You don't know... (0)

Anonymous Coward | about 3 months ago | (#47343569)

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. :/

Re:You don't know... (2)

amorsen (7485) | about 3 months ago | (#47343761)

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.

If a tree falls in a forest... (4, Informative)

Sits (117492) | about 3 months ago | (#47342109)

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 [blogspot.co.uk] (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 [blogspot.co.uk] ). 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.

Safe Buffer? (3)

Midnight Thunder (17205) | about 3 months ago | (#47342329)

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? (1)

Anonymous Coward | about 3 months ago | (#47342421)

The real question is why can't programmers figure out how to do bounds checking.
It's not exactly rocket science.
Just make a struct with an array pointer and a size int.

Re:Safe Buffer? (3, Insightful)

Anonymous Coward | about 3 months ago | (#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

Re:Safe Buffer? (0)

Anonymous Coward | about 3 months ago | (#47342567)

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.

And yet some people (most programmers, that is) are going to be far, far, far, far, far more lazy, stupid, and careless than others.

Re:Safe Buffer? (0)

Anonymous Coward | about 3 months ago | (#47342869)

I think that making every access to a C array bound checked is not feasible imho.
An array type with bounds checking in the standard library would be nice, but that would still rely on the programmer using it correctly.

Re:Safe Buffer? (1)

aix tom (902140) | about 3 months ago | (#47345707)

And to further the argument: Is a glass manufacturer lazy/stupid/careless when he sells non-bullet proof glass for $X, and not makes it a point to only sell bullet-proof glass at $X * 100?

The same way I just have to accept that the door to my balcony is not going to stop a man with a ladder and a sledgehammer and ~15 minutes time, I have to accept that "normal" computer security won't keep me 100% save, unless I invest some time and effort myself, or pay someone to do the effort, way above "the norm" to make me "saver than the norm"

Re:Safe Buffer? (1)

funky_vibes (664942) | about 3 months ago | (#47344161)

Because it's not the right solution for every problem, and if you make languages that *force* this kind of behaviour, the shitty programmer will just put their bugs elsewhere.
The solution is to simply write better code.

Re:Safe Buffer? (0)

Anonymous Coward | about 3 months ago | (#47344253)

Bounds checking is easy. Dealing with C's idiotic, bizantine, outright evil type promotion rules, isn't.

Re: Safe Buffer? (1)

Anonymous Coward | about 3 months ago | (#47342429)

The folks who designed ALGOL already thought abouts this and have it. They even built entire Mainframe operating systems using ALGOL variants. They had fine-grained security protection inside each program, each library. Not just the ÂMMU will hopefully contain any C-based exploit at the process levelÂ. They sold this as the MCP OS since 1961. They still do. The Russians have a similar OS and so did Britains ICL corporation.

But you now what ? Cheap and nasty C, Unix, MSDOS, Windows have somehow eliminated most of these mainframe businesses and the people who developed software for them. It also created a wonderful opportunity for the Military Industrial Complex to have a new Âwarfare domainÂ.

But hey, that is just in line with the general deterioration of the West, when people dont know how to cook food any more. You can have that McFatty Burger with a McScheiss Programming language and a McCheap operating system.

Software engineers will be McBrogrammers and exist just above welfare level.

Re: Safe Buffer? (0)

Anonymous Coward | about 3 months ago | (#47343289)

I'm not sure why you are blaming "cheap and nasty" for "winning."

Kind of like saying the local hooker is popular, but noone dares hit on the king's daughter, so she died alone
in her palace.

Bits are cheap. What are we talking here, 1G tops?

Is MCP code available? Binaries? What CPUs? What platforms?

Lets get things on the road, instead of just bitching.

Who is holding it back? The world, or the vendor(s)?

We can even run C on it, just to spite you.

Got a link?

Re: Safe Buffer? (-1)

Anonymous Coward | about 3 months ago | (#47343307)

In other news, most families can't afford caviar every night.

Stupid poor people, making sensible choices and living within their means. IDIOTS.

Re:Safe Buffer? (2)

fnj (64210) | about 3 months ago | (#47342505)

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.

Safe code not about ability to make it safe... (1)

Thinking Tom (2073828) | about 3 months ago | (#47342627)

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.

Re:Safe Buffer? (2)

leuk_he (194174) | about 3 months ago | (#47343903)

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:Safe Buffer? (1)

guruevi (827432) | about 3 months ago | (#47343507)

Once you start checking bounds and counting references and making strings safe and cleaning memory and garbage collection you're in the realm of ObjC, Java and other higher languages. They exist, they are available and can be used to implement any algorithm imaginable. Yet programmers still use C, Assembler and even PROM...

Re:Safe Buffer? (0)

Anonymous Coward | about 3 months ago | (#47351045)

Exactly! Why did they add comparison instructions in the sets in the first place! If I need to parse an array, let another (not mine) piece of code check bounds. Still... I wonder how one would build such a construct in a not-yet-invented language. Anyways, in our era, programmers shouldn't have to care/think/know how and why to do thing, just focus on delivery...

Re:Safe Buffer? (1)

david_thornley (598059) | about 3 months ago | (#47352161)

If we're talking about stuff in the kernel, we're talking about needing performance with minimal runtimes. This usually rules out the usual garbage collection. At that point, you probably should consider C++, which provides string and array equivalents with bounds checking but is as efficient as C.

Re:Safe Buffer? (1)

guruevi (827432) | about 3 months ago | (#47354849)

But that's what I mean. However, C++ is slower than C, C is simpler to implement and virtually any platform has a C compiler but it doesn't do a lot of things out of the box. You choose the tool you need and best suited for the job. I can't program a PIC in JavaScript, but I can do a website.

Re:Safe Buffer? (1)

david_thornley (598059) | about 3 months ago | (#47360275)

C++ is very rarely slower than C (particularly if you can disable exceptions), and is sometimes faster (std::sort vs qsort). It doesn't actually require a complicated runtime. These are important differences between it and Java.

If you need C-like performance, want security, and have a good C++ compiler (g++, clang, to some extent VC++), C++ is a very good choice.

Re:Safe Buffer? (1)

sproketboy (608031) | about 3 months ago | (#47344071)

They have. It's called Java or C#.

Re:Safe Buffer? (1)

david_thornley (598059) | about 3 months ago | (#47352131)

C++ has safe buffers in the standard library.

LZW is pretty simple (0)

Anonymous Coward | about 3 months ago | (#47342525)

I wrote my own GIF codec 20 years ago, the whole algorithm could fit on two screen pages.

32bit OS / 32bit app or 32bit cpu (1)

Joe_Dragon (2206452) | about 3 months ago | (#47343379)

32bit OS / 32bit app or 32bit cpu

Re:32bit OS / 32bit app or 32bit cpu (0)

Anonymous Coward | about 3 months ago | (#47346875)

32-bit long int.

c/c++ (1)

Anonymous Coward | about 3 months ago | (#47343841)

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

Re:c/c++ (0)

Anonymous Coward | about 3 months ago | (#47343919)

What? Even after reading over the spelling errors I still do not get the joke. Is is a joke?

Hmm.. (0)

Anonymous Coward | about 3 months ago | (#47344563)

Seems the bug also affects the writer's spell-checking utility.

Grain of salt.... (1)

rew (6140) | about 3 months ago | (#47345399)

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.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>