Thread (16 messages) 16 messages, 6 authors, 2016-08-14

Re: [PATCH] [RFC] Introduce mmap randomization

From: Jason Cooper <hidden>
Date: 2016-07-28 21:07:50
Also in: lkml

On Wed, Jul 27, 2016 at 09:59:35AM -0700, Nick Kralevich wrote:
On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper [off-list ref] wrote:
quoted
quoted
quoted
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.
Ok, I buy that with the 64bit-only caveat.
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.
One person calls "unmapped gaps between pages" a feature, others call it
a mess. ;-)
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.
Agreed.

thx,

Jason.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help