User: Password:
|
|
Subscribe / Log in / New account

Kernel vulnerabilities: old or new?

Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 8:33 UTC (Wed) by intgr (subscriber, #39733)
Parent article: Kernel vulnerabilities: old or new?

According to several posts I've seen here, some of these bugs were already prevented by grsec kernels prior to their discovery in mainline.

Is this true?

Why aren't relevant grsec patches moving to mainline? It can't be just that nobody bothers to submit them to mainline. One would think that even if grsec developers aren't interested, then other security-conscious devs would review and cherry-pick patches from the grsec tree and submit them for the mainline. But I get the impression that no cooperation is happening at all.


(Log in to post comments)

Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 18:35 UTC (Wed) by kees (subscriber, #27264) [Link]

Not only did those protections stop many of the vulnerabilities from being exploited, some of the vulnerabilities were discovered _because_ of the protections (see the history on how CVE-2010-2955 got reported).

The main difficulty with getting PaX and grsec protections into mainline is that the patchset is hard to separate into individual pieces. Additionally, many of the protections are done in a way that mainline folks do not like for various technical reasons. I suspect the only way to get these protections into mainline is to have someone (or better yet, a group of people) fighting for them that:
a) understands the code
b) understands why it is important
c) have the time to advocate for it and revise patches until they get in

So far, no one has really had all 3. Plenty of people get "b" (even if they don't have "a"), and "c" is insanely frustrating given the attitudes of the mainline maintainers towards security.

Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 21:14 UTC (Wed) by clugstj (subscriber, #4020) [Link]

How about
d) are not so hardheaded that they will actually listen to what other people say.

Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 23:42 UTC (Wed) by jamesmrh (guest, #31622) [Link]

Kees listened to what upstream folk said, but was lead in circles by them, and ultimately his Yama code was vetoed.

I'm not sure what the solution is.

Users can request the protections be added to their distros, which will at least get them better protected, and possibly help make a stronger case for upstream inclusion.

Another possibility is for a company with a strong involvement in Linux to hire someone with the traits a & b above, to act as a system-wide security coordinator / advocate. i.e. make it someone's paid job to work on kernel hardening.

Kernel vulnerabilities: old or new?

Posted Oct 21, 2010 9:15 UTC (Thu) by patrick_g (subscriber, #44470) [Link]

>>> Another possibility is for a company with a strong involvement in Linux to hire someone

Why not the Linux foundation ? Perhaps they can sponsors a few security experts ?
There is a "Linux fellow program" here => https://www.linuxfoundation.org/programs/developer/fellowship

Kernel vulnerabilities: old or new?

Posted Oct 21, 2010 11:30 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> Additionally, many of the protections are done in a way that mainline folks do not like for various technical reasons.

Would you be able elaborate on that, or provide a couple of pointers? (Sorry for lazily asking rather than researching myself!)

Kernel vulnerabilities: old or new?

Posted Oct 21, 2010 11:34 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> > Additionally, many of the protections are done in a way that mainline folks do not like for various technical reasons.

> Would you be able elaborate on that, or provide a couple of pointers? (Sorry for lazily asking rather than researching myself!)

Replying to myself - probably http://userweb.kernel.org/~jmorris/lss2010_slides/out-of-... will be one of the pointers.

Kernel vulnerabilities: old or new?

Posted Oct 24, 2010 12:09 UTC (Sun) by vonbrand (guest, #4458) [Link]

Sorry, but "widely used" isn't really an argument... the saying here goes "10,000,000,000,000 flies eat sh*t, so should you"

Kernel vulnerabilities: Promoting protection

Posted Oct 29, 2010 20:43 UTC (Fri) by jageorge (guest, #61413) [Link]

The biggest problem in this domain is one of egos. Influential kernel developers who don't care about stuff that they don't own, and security hackers who want to see their names in lights.

In the case of kernel hackers there is a tendency to use excuses which boil down to shooting down solutions which don't have a perfect "model" for resolving an exploit or class of exploits. (AppArmor) Also, kernel hackers tend to hate large patches which actually address a bunch of conceptually separate issues to the point where the aggregate gets blown off. (GrSec)

Security hackers on the other hand will legitimately discover bugs, but don't like Linus's attitude that their presumably security compromising exploit bugs are no more worthy of special recognition than any other kernel bug. Furthermore, there is a tendency to provide "fixes" which simply shift the point of exploitable failure from a current failure to a future or even concurrent failure point. This is sometimes combined with with creating solutions to a bunch of small kernel vulnerabilities in combination with larger frameworks which make them harder to apply to the root cause problems and to audit. There is sometimes a lack of consideration of balancing of performance, scalability, and complexity considerations against quick and dirty or overly complex framework solutions. Finally, there is often a desire to re-invent the wheel rather than understanding and working with existing robustness models.

The Solution (tm):
1. Preview solutions with key kernel developers who are interested in security.
2. Request reviews from other key kernel developers who can help with feedback.
3. Treat different conceptual problems with different patch sets. Debugging, tracing, simple patches, class of exploit preventions, etc.
4. Performance matters.
5. Compatibility matter even more. Breaking X.org, FTP, SSH, procfs, udev, or Apache is not OK. :-)
6. We already have SELinux and AppArmor - don't reinvent the wheel - invent the tire instead.
7. Document your work... When has this been a problem? Why should people care now? What is the design of the solution? Why couldn't it be simpler? Are there benchmarks? What issues were identified in review and how were they addressed?

I really wish that security (and performance) were addressed in a more rigorous fashion, but the best we can hope for is learning how to work together and maybe getting a corporate sponsor. :-)

Kernel vulnerabilities: old or new?

Posted Oct 20, 2010 18:36 UTC (Wed) by spender (subscriber, #23067) [Link]

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]

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).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds