[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1299198769.8493.2981.camel@nimitz>
Date: Thu, 03 Mar 2011 16:32:49 -0800
From: Dave Hansen <dave@...ux.vnet.ibm.com>
To: Matt Mackall <mpm@...enic.com>
Cc: Dan Rosenberg <drosenberg@...curity.com>, cl@...ux-foundation.org,
penberg@...nel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Make /proc/slabinfo 0400
On Thu, 2011-03-03 at 17:08 -0600, Matt Mackall wrote:
> > 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.
Kees Cook was nice enough to point out a few of the ways this can get
misused. It looks like the basic pattern is to use slabinfo to
determine where an object was likely to have been allocated in the slab
in order to more precisely target the next stage of the attack.
I do see how much easier slabinfo makes this. Do any of the attacks
that we know about rely on anything _but_ trying to figure out when a
slab page got consumed?
If I were an attacker, I'd probably just start watching /proc/meminfo
for when Slab/SReclaimable/SUnreclaim get bumped. That'll also give me
a pretty good indicator of where my object is in the slab.
Granted, doing that still puts one more level of opaqueness in the way.
slabinfo definitely makes it more straightforward.
-- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists