Re: [PATCH] Make /proc/slabinfo 0400

[Matt Mackall]

On Mon, 2011-03-07 at 09:56 -0500, Dan Rosenberg wrote:
> On Sun, 2011-03-06 at 13:19 +0000, Alan Cox wrote:
> > > If we had wrappers for the most common cases, then any cases that were
> > > left that used copy_from_user() explicitly could be flagged and
> > > checked by hand, since they would be exception, and not the rule.
> > 
> > Arjan's copy_from_user validation code already does verification checks
> > on the copies using gcc magic.
> > 
> > Some of the others might be useful - kmalloc_from_user() is a fairly
> > obvious interface, a copy_from_user_into() interface where you pass
> > the destination object and its actual length as well is mostly covered by
> > Arjan's stuff.
> > 
> > Alan
> 
> This is all worthwhile discussion, and a good implementation of these
> kinds of features is available as part of grsecurity (PAX_USERCOPY) - it
> provides additional bounds-checking for copy operations into both heap
> and stack buffers.  Rather than reinventing the wheel, perhaps it would
> be a better use of time to extract this patch and make it suitable for
> inclusion.

Bounds-checking the existing generic functions is not at all the same,
and is in fact counterproductive. It says "go ahead, think even LESS
about getting your code right, because there's a (slow) safety net
built-in".

The above proposal is instead "copy these patterns that simplify your
code"

Consider time_after:

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/include/linux/jiffies.h#L93

Before this code (now more than 10 years old), there was lots of code in
the kernel that manually compared time stamps and got it wrong. These
error would show up about 43 days later when someone on an Alpha would
get a panic. We eventually ended up setting the clock to wrap after only
5 minutes and hundreds of these bugs showed up. The fix was not to try
to catch unlikely timer values, but to instead make it easy to get the
code right.

> In the meantime, I'd like to get back to the original patch
> (make /proc/slabinfo 0400), and the subsequent followup patch (randomize
> free objects within a slab).  While it's clear that these patches by
> themselves will not entirely prevent kernel heap exploits, they both
> seem to be sane improvements, won't significantly impact performance,
> and shouldn't be more than a very minor inconvenience to some small
> subset of normal users.  In addition, the absence of these changes might
> undermine future hardening improvements (e.g. with a more hardened heap,
> the readability of /proc/slabinfo may be more necessary for successful
> exploitation).

If a "hardened heap" ever shows up which doesn't have the massive
overhead of a debugging heap and is thus interesting to the real world,
we can consider these changes then. But I won't be holding my breath.

The only method I know of to harden a heap that would prevent the
exploits we're looking at is basically CONFIG_PAGE_DEBUG: put each
object on a separate page and surround it by two not-present pages. Then
any overflow gets caught instantaneously by the MMU. Before anyone gets
excited about this approach: having 96-byte objects take 4k of physical
memory, 12k of virtual memory, and have massive TLB flushing overhead is
a great way to make your i7 feel like a 386.

Every other method that doesn't rely on hardware (eg redzoning) is only
defense against accidental overruns and will only catch problems long
after the fact. Further, if you can inject exploit code into a
neighboring object, you can probably properly repair the redzone while
you're at it.

The kind of randomization that defends address spaces won't work here.
That requires a vast amount of virtual memory to be any defense against
NOP sleds or equivalents. And we've only got physical space around the
size of a page to play with. If the attacker can control allocation of
lots of objects, we basically have to assume that space is crowded.

-- 
Mathematics is the supreme nostalgia of our time.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/