Re: [PATCH] Make /proc/slabinfo 0400

[Matt Mackall]

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.


--
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/