lkml.org 
[lkml]   [2016]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] [RFC] Introduce mmap randomization
    On Tue, Jul 26, 2016 at 1:59 PM, Jason Cooper <jason@lakedaemon.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@google.com | 650.214.4037

    \
     
     \ /
      Last update: 2016-07-27 19:41    [W:3.238 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site