Message-ID: <476DC76E7D1DF2438D32BFADF679FC5601276FB4@ORSMSX103.amr.corp.intel.com>
Date:	Tue, 2 Aug 2016 16:57:48 +0000
From:	"Roberts, William C" <william.c.roberts@...el.com>
To:	Nick Kralevich <nnk@...gle.com>,
	Jason Cooper <jason@...edaemon.net>
CC:	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"kernel-hardening@...ts.openwall.com" 
	<kernel-hardening@...ts.openwall.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"jeffv@...gle.com" <jeffv@...gle.com>,
	"salyzyn@...roid.com" <salyzyn@...roid.com>,
	"dcashman@...roid.com" <dcashman@...roid.com>
Subject: RE: [PATCH] [RFC] Introduce mmap randomization



> -----Original Message-----
> From: Nick Kralevich [mailto:nnk@...gle.com]
> Sent: Wednesday, July 27, 2016 10:00 AM
> To: Jason Cooper <jason@...edaemon.net>
> Cc: Roberts, William C <william.c.roberts@...el.com>; linux-mm@...ck.org;
> linux-kernel@...r.kernel.org; kernel-hardening@...ts.openwall.com;
> akpm@...ux-foundation.org; keescook@...omium.org;
> gregkh@...uxfoundation.org; jeffv@...gle.com; salyzyn@...roid.com;
> dcashman@...roid.com
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
> 
> On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper <jason@...edaemon.net> wrote:
> >> > One thing I didn't make clear in my commit message is why this is
> >> > good. Right now, if you know An address within in a process, you
> >> > know all offsets done with mmap(). For instance, an offset To libX
> >> > can yield libY by adding/subtracting an offset. This is meant to
> >> > make rops a bit harder, or In general any mapping offset mmore difficult to
> find/guess.
> >
> > Are you able to quantify how many bits of entropy you're imposing on
> > the attacker?  Is this a chair in the hallway or a significant
> > increase in the chances of crashing the program before finding the desired
> address?
> 
> Quantifying the effect of many security changes is extremely difficult, especially
> for a probabilistic defense like ASLR. I would urge us to not place too high of a
> proof bar on this change.
> Channeling Spender / grsecurity team, ASLR gets it's benefit not from it's high
> benefit, but from it's low cost of implementation
> (https://forums.grsecurity.net/viewtopic.php?f=7&t=3367). This patch certainly
> meets the low cost of implementation bar.
> 
> In the Project Zero Stagefright post
> (http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html),
> we see that the linear allocation of memory combined with the low number of
> bits in the initial mmap offset resulted in a much more predictable layout which
> aided the attacker. The initial random mmap base range was increased by Daniel
> Cashman in d07e22597d1d355829b7b18ac19afa912cf758d1, but we've done
> nothing to address page relative attacks.
> 
> Inter-mmap randomization will decrease the predictability of later
> mmap() allocations, which should help make data structures harder to find in
> memory. In addition, this patch will also introduce unmapped gaps between
> pages, preventing linear overruns from one mapping to another another
> mapping. I am unable to quantify how much this will improve security, but it
> should be > 0.
> 
> I like Dave Hansen's suggestion that this functionality be limited to
> 64 bits, where concerns about running out of address space are essentially nil. I'd
> be supportive of this change if it was limited to
> 64 bits.

Sorry for the delay on responding, I was on vacation being worthless. Nick, very eloquently,
described what I failed to put in the commit message. I was thinking about this on vacation
and also thought that on 64 bit the fragmentation shouldn't be an issue.

@nnk, disabling ASLR via set_arch() on Android, is that only for 32 bit address spaces where
you had that problem?

Powered by blists - more mailing lists