linux-kernel - Re: [PATCH] [RFC] Introduce mmap randomization

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]

Message-ID: <CAFJ0LnEZW7Y1zfN8v0_ckXQZn1n-UKEhf_tSmNOgHwrrnNnuMg@mail.gmail.com>
Date:	Wed, 27 Jul 2016 09:59:35 -0700
From:	Nick Kralevich <nnk@...gle.com>
To:	Jason Cooper <jason@...edaemon.net>
Cc:	"Roberts, William C" <william.c.roberts@...el.com>,
	"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

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.

-- Nick

-- 
Nick Kralevich | Android Security | nnk@...gle.com | 650.214.4037