Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 18:36 UTC (Wed) by spender (guest, #23067)
In reply to: Kernel vulnerabilities: old or new? by intgr
Parent article: Kernel vulnerabilities: old or new?

We don't necessarily prevent the bugs themselves, though it is true we sometimes have fixes for things that aren't fixed in mainline. I imagine what you mean is that exploitation of the bugs is prevented in grsec kernels. That's been true in many cases at different levels.

Often, we turn vulnerabilities that can be exploited for privilege elevation into DoSes. The reason is that we've detected something that shouldn't have happened that we know can be abused, so it's not safe to allow the system to continue running.

Some vulnerabilities are prevented completely, like those of the form:
buf = kmalloc(attacker_controlled_size * something, GFP_ANYTHING);
instead of overflowing and allowing exploitation, we detect the overflow and cause buf to be set to NULL. We also add additional bounds checking to copy_*_user calls, both against the kernel stack and kernel heap.

Other features of grsecurity prevent exploitation of certain bugs by reducing attack surface. For example, GRKERNSEC_MODHARDEN prevents attackers from auto-loading an unused kernel module just so that it can be exploited. This reduces the risk from numerous obscure driver vulnerabilities (like the recent RDS vulnerability).

Finally, a number of features of grsecurity and PaX work together to make exploitation of the remaining vulnerabilities quite difficult in many cases. Symbol hiding, PAX_KERNEXEC, and PAX_UDEREF all work together to make the kernel a hostile environment to attackers. In general, memory corruption exploits should require an arbitrary read bug in addition to whatever vulnerability is being exploited. Any exploits have to be written considerably different as the ring-0 payload to execute can no longer be located in userland (as it is with every public exploit in existence).

Since we have a couple more people now writing exploits (Kees, Tavis, Dan) I'd actually like to see a memory corruption exploit that works against a grsec kernel with a writeup about the process involved.

-Brad

Kernel vulnerabilities: old or new?

Posted Oct 21, 2010 16:51 UTC (Thu) by ccurtis (guest, #49713) [Link] (1 responses)

I'm speaking from an uninformed position here so I may just be regurgitating marketing I've heard, but it seems like Microsoft has really taken a leadership position in securing the NT kernel.

Their biggest problem (in recent history) has always been in 3rd party drivers, but I hear less and less about these being exploited lately. Have they sufficiently hardened their DDK to prevent the majority of these problems? Is there something about their driver architecture - some microkernel-esque fault isolation perhaps - that prevents wider system compromise?

I don't see how you could prevent a driver from, say, dereferencing a NULL pointer, but it seems like it would be a nice feature to have a lower barrier to entry for device driver writers. Specifically: can the Linux driver model be crafted such that a hardware manufacturer can provide a driver (in source code form or otherwise) that is sloppily written yet not expose the kernel to further breach? Would running drivers in ring1 instead of ring0 achieve this?

Requiring perfect code in order to support a device, while ideal, seems like a long-term losing proposition. One could make the same argument for network protocols or file systems.

Is this a reasonable goal or is it overkill? Is it anything other than a microkernel architecture that's been dismissed out of hand since Linux 0.01? And perhaps philosophically, is it reasonable to even consider killing and respawning a misbehaving driver?

It seems like what I'm really thinking of is a [fixed] kernel API for drivers, but I expect this has already been discussed and rejected many times over. But for example, when descending the drivers/ directory, the 'kmalloc' symbol can be #defined to something invalid, forcing drivers to use ddk_malloc() which has grsec-style checking built-in. (This "kernel API" would be a family of ddk_xxxx() calls.)

Alternately, for code paths where it's deemed more important to be fast than safe (scheduler, SL*B allocators, other "core" code), there can be an audited/ tree as the only place where code has access to versions of the system calls that aren't encumbered by security restrictions. (The ddk_xxxx() calls would naturally live here.)

Or is this just not seen as a problem?

Kernel vulnerabilities: old or new?

Posted Oct 21, 2010 17:27 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

Ring 1? Isn't this x86-specific?

What would happen in a VM?

And why are you using a crappy out-of-tree driver anyway? (yeah, I know, I shouldn't be writing that specific comment).