lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ