lkml.org 
[lkml]   [2011]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] Make /proc/slabinfo 0400
From
Date
On Thu, 2011-03-03 at 17:30 -0500, Dan Rosenberg wrote:
> > Well if it were a 1000x-1000000x difficulty improvement, I would say you
> > had a point. But at 10x, it's just not a real obstacle. For instance, in
> > this exploit:
> >
> > http://www.exploit-db.com/exploits/14814/
> >
> > ..there's already detection of successful smashing, so working around
> > not having /proc/slabinfo is as simple as putting the initial smash in a
> > loop. I can probably improve my odds of success to nearly 100% by
> > pre-allocating a ton of objects all at once to get my own private slab
> > page and tidy adjoining allocations. I'll only fail if someone does a
> > simultaneous allocation between my target objects or I happen to
> > straddle slab pages.
> >
>
> For this particular exploit, the allocation and triggering of the
> vulnerability were in separate stages, so that's the case, but other
> exploits might have additional constraints. For example, there is a
> public exploit for a two-byte SLUB overflow that relies on a partial
> overwrite into a free chunk; exploitation of vulnerabilities similar to
> this may be significantly hindered by the lack of availability of this
> interface. Still other issues may only get one shot at exploitation
> without needing to clean up corrupted heap state to avoid panicking the
> kernel. In short, every exploit is different, and exposure
> of /proc/slabinfo may be the thing that puts some more difficult cases
> within reach.
>
> > And once an exploit writer has figured that out once, everyone else just
> > copies it (like they've copied the slabinfo technique). At which point,
> > we might as well make the file more permissive again..
> >
>
> This may be true to some extent, but kernel vulnerabilities tend to be
> somewhat varied in terms of exploitation constraints, so I'm not
> convinced a general technique would apply to enough cases to render this
> change completely pointless.
>
> Many security features, for example NX enforcement, have not proven to
> be especially significant in completely mitigating exploitation of
> userland memory corruption vulnerabilities by themselves, given the
> advent of code-reuse exploitation techniques. They have also come at
> the cost of breaking some applications. However, the reason we don't
> just turn them all off is because they provide SOME hurdle, however
> small, and given enough incremental improvements, we eventually get to
> the point where things are actually hard.
>
> > > > On the other hand, I'm not convinced the contents of this file are of
> > > > much use to people without admin access.
> > > >
> > >
> > > Exactly. We might as well do everything we can to make attackers' lives
> > > more difficult, especially when the cost is so low.
> >
> > There are thousands of attackers and millions of users. Most of those
> > millions are on single-user systems with no local attackers. For every
> > attacker's life we make trivially more difficult, we're also making a
> > few real user's lives more difficult. It's not obvious that this is a
> > good trade-off.
> >
>
> I appreciate your input on this, you've made very reasonable points.
> I'm just not convinced that those few real users are being substantially
> inconvenienced, even if there's only a small benefit for the larger
> population of users who are at risk for attacks. Perhaps others could
> contribute their opinions to the discussion.

That's my hope, as I'm basically on the fence.

--
Mathematics is the supreme nostalgia of our time.




\
 
 \ /
  Last update: 2011-03-04 00:11    [W:0.094 / U:1.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site