Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1452102

Re: [PATCH] [RFC] Introduce mmap randomization

Show all headers | View raw

On Wed, Jul 27, 2016 at 09:59:35AM -0700, Nick Kralevich wrote:
> 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.

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.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH] [RFC] Introduce mmap randomization william.c.roberts@intel.com - 2016-07-26 20:30 +0200
  [PATCH] [RFC] Introduce mmap randomization william.c.roberts@intel.com - 2016-07-26 20:30 +0200
    Re: [PATCH] [RFC] Introduce mmap randomization Jason Cooper <jason@lakedaemon.net> - 2016-07-26 22:10 +0200
      RE: [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-07-26 22:20 +0200
      RE: [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-07-26 22:20 +0200
        RE: [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-07-26 23:10 +0200
          Re: [PATCH] [RFC] Introduce mmap randomization Jason Cooper <jason@lakedaemon.net> - 2016-07-26 23:50 +0200
            Re: [PATCH] [RFC] Introduce mmap randomization Dave Hansen <dave.hansen@intel.com> - 2016-07-27 02:00 +0200
            RE: [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-08-02 19:30 +0200
              RE: [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-08-03 20:20 +0200
          RE: [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-08-02 19:40 +0200
        Re: [PATCH] [RFC] Introduce mmap randomization Jason Cooper <jason@lakedaemon.net> - 2016-07-26 23:10 +0200
          Re: [PATCH] [RFC] Introduce mmap randomization Nick Kralevich <nnk@google.com> - 2016-07-27 19:00 +0200
            Re: [PATCH] [RFC] Introduce mmap randomization Jason Cooper <jason@lakedaemon.net> - 2016-07-28 23:10 +0200
              Re: [kernel-hardening] Re: [PATCH] [RFC] Introduce mmap  randomization Daniel Micay <danielmicay@gmail.com> - 2016-07-29 12:20 +0200
                Re: [kernel-hardening] Re: [PATCH] [RFC] Introduce mmap randomization Jason Cooper <jason@lakedaemon.net> - 2016-08-01 00:30 +0200
                Re: [kernel-hardening] Re: [PATCH] [RFC] Introduce mmap  randomization Daniel Micay <danielmicay@gmail.com> - 2016-08-01 02:30 +0200
            RE: [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-08-02 19:00 +0200
              Re: [PATCH] [RFC] Introduce mmap randomization Nick Kralevich <nnk@google.com> - 2016-08-02 19:20 +0200
    Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization Rik van Riel <riel@redhat.com> - 2016-07-26 22:20 +0200
      RE: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-07-26 22:20 +0200
    Re: [PATCH] [RFC] Introduce mmap randomization Nick Kralevich <nnk@google.com> - 2016-07-26 22:50 +0200
      RE: [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-07-26 23:10 +0200
        Re: [PATCH] [RFC] Introduce mmap randomization Nick Kralevich <nnk@google.com> - 2016-07-26 23:20 +0200
  RE: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization "Roberts, William C" <william.c.roberts@intel.com> - 2016-08-04 19:00 +0200
    Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization Daniel Micay <danielmicay@gmail.com> - 2016-08-04 19:20 +0200
  Re: [kernel-hardening] [PATCH] [RFC] Introduce mmap randomization Daniel Micay <danielmicay@gmail.com> - 2016-08-04 19:10 +0200

csiph-web