Which is which [LWN.net]

Which is which

Posted Jul 24, 2009 9:59 UTC (Fri) by nix (subscriber, #2304)
In reply to: Which is which by man_ls
Parent article: Quotes of the week

The problem is that modern systems are so horribly complicated and have a high enough security hole density that I fear that whack-a-mole exploit squashing will never get us to a secure state. Shaming developers only helps to kill exploits in the same way that shaming developers works to eliminate all bugs: it might reduce the density but only to a point, and it doesn't really matter if you have one security hole on your system or six, the bad guys will still get in. And even if the universally-used core of the kernel *does* get all its security bugs squashed, the vast mass of drivers run by only a few people (but which many people run at least one of) will still have holes, as will the vast tower of userspace above it, much of which is run by almost everyone.

So attacking kernel devs for 'covering up' holes is pointless: most security threats are in the layers above it, particularly as most cracks these days are financially-motivated and don't care about getting root so much as spying on you, making you a botnet node, and sending out spam, all of which can be done without root. I don't notice Brad howling about FF even though its security record is much worse than the kernel's of late (but they have a webpage saying which security bugs they fixed! that solves everything! oh wait, it doesn't). You surely can't accuse the kernel devs of *not fixing* security holes when they are pointed out: they just don't make a great song-and-dance about it (it's probably wisest to assume that any bug in something all-powerful like the kernel, or something network-facing like FF, is a potential security hole).

Now kernel bugs *are* dangerous --- it's easier to write a seriously infective worm using a kernel remote root exploit than an FF bug --- but are they worth paying so much more attention to than the higher layers?

Perhaps capabilities would have saved us from the insecurity of modern systems, but it's very non-POSIX and Shapiro has been eaten by Microsoft now so we won't see anything from that until a new caps deity emerges. Certainly any number of paranoid bug-hunters aren't going to solve the problem.

Perhaps writing the higher-level stuff in languages better than C would save us, although that would probably just mean attackers finding some other way to force programs to do unexpected things. That'll happen as long as machines can make choices in response to external input, but we could probably get their density down a long way. Then maybe focusing on the kernel to the exclusion of all else would make sense.

If we must use C, randomly perturbing the ABI on each installed system might help a bit (there's been work on this in the past): but it would be difficult, wouldn't stop all exploits by any means, and would break distribution of binaries.

I have no solutions, but what we're doing now surely isn't going to fix anything. Holding back the tide is very praiseworthy, but in the long run gets you nowhere.

(Log in to post comments)

Which is which

Posted Jul 24, 2009 20:37 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, yes, of course, but most attacks on higher-level stuff don't bother
trying to exploit a kernel bug in order to get at, say, Firefox. They
buffer-overrun some image library instead (FF does things like ship its
own copy of that known security-wobbly library libpng, always, because
some patch of theirs was rejected from the upstream tree, sigh). I'm not
sure I've ever heard of userspace network-facing software such as web
browsers being successfully attacked by way of a kernel hole. I suppose it
*could* happen, and perhaps it has, but is it common enough to make the
kernel a more worthwhile thing to fix than the higher-level stuff? It
seems more likely they'd stick to attacking the higher layer, and thus get
an exploit that works no matter what version of the kernel you're running.

(Damn good interview, btw.)

Which is which

Posted Jul 24, 2009 22:36 UTC (Fri) by spender (subscriber, #23067) [Link]

My mention of "kernel protections" referred to NX/ASLR/etc, which are implemented in the kernel ;)

-Brad

Which is which

Posted Jul 25, 2009 12:34 UTC (Sat) by nix (subscriber, #2304) [Link]

Ah, yes, obviously they're worthwhile. Still there seems to be a
depressing frequency of vulns (exploitable even with these protections) in
the higher levels: the days when the kernel had more holes than everything
else put together seem to be behind us.

Killing bugs

Posted Jul 25, 2009 0:37 UTC (Sat) by man_ls (subscriber, #15091) [Link]

Of course we (kernel users) don't want kernel developers to just fix a few exploited bugs as they come up. What we really want (and have got a taste of in this situation) is developers to close gaping holes and eliminate whole categories of errors. People are integrating protections against Brad's clever exploits at all levels; and as it happens the main bug exploited here had been reported by Coverity, so maybe kernel devs will listen to these reports. It might take a few more exploits but Brad has got their attention now.

We all make mistakes; good engineering should prevent known mistakes from happening again, or at least from taking down the whole system with them. Two buffer overflows is one too much. This probably means doing work at several different levels (language, compiler, memory libraries, code checkers, audit tools, security modules), but we will all be better off for the next round of attacks, which may come from less benign sources. This is the fundamental truth which we probably all knew, but had forgotten; we have to be reminded every now and then.

Killing bugs

Posted Jul 27, 2009 12:32 UTC (Mon) by hppnq (guest, #14462) [Link]

Of course we (kernel users) don't want kernel developers to just fix a few exploited bugs as they come up. [ ... ] We all make mistakes; good engineering should prevent known mistakes from happening again, or at least from taking down the whole system with them. [ ... ] This is the fundamental truth which we probably all knew, but had forgotten; we have to be reminded every now and then.

I think the fundamental truths here are: 1) any usable system can be abused, and 2) all resources are limited. Laws of nature.

This then means that, if you care about actual security, it is far more important to do things like kicking pulseaudio off of your precious servers and monitoring what gets run by which user. What we need are not perfectly engineered systems -- of course it helps if developers try a bit -- but fault tolerant systems.

And then, of course, there remains plenty of time and energy to discuss full disclosure, bug class reporting, static code analysis and auditing, and how useful these are or would be. That entire discussion also revolves around laws 1 and 2, and these are also the points that people will either forget or, worse, ridicule.

Oh, and make regular backups. ;-)