RE: [PATCH] [RFC] Introduce mmap randomization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: Kirill A. Shutemov [mailto:kirill@xxxxxxxxxxxxx]
> Sent: Tuesday, July 26, 2016 12:26 PM
> To: Roberts, William C <william.c.roberts@xxxxxxxxx>
> Cc: linux-mm@xxxxxxxxx
> Subject: Re: [PATCH] [RFC] Introduce mmap randomization
> 
> On Tue, Jul 26, 2016 at 11:27:11AM -0700, william.c.roberts@xxxxxxxxx wrote:
> > From: William Roberts <william.c.roberts@xxxxxxxxx>
> >
> > This patch introduces the ability randomize mmap locations where the
> > address is not requested, for instance when ld is allocating pages for
> > shared libraries. It chooses to randomize based on the current
> > personality for ASLR.
> >
> > Currently, allocations are done sequentially within unmapped address
> > space gaps. This may happen top down or bottom up depending on scheme.
> >
> > For instance these mmap calls produce contiguous mappings:
> > int size = getpagesize();
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40026000
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40027000
> >
> > Note no gap between.
> >
> > After patches:
> > int size = getpagesize();
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x400b4000
> > mmap(NULL, size, flags, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40055000
> >
> > Note gap between.
> 
> And why is it good?

Currently if you get an info leak and discover, say the address to libX
It's just a matter of adding/subtracting a fixed offset to find libY. This
will make rop a bit harder if you're trying to rop into a different library
than what was leaked.

This also has a benefit outside of just libraries in that it randomizes all the
Mappings done via mmap from run to run. So you don't get consistent,
known offsets to things within the memory space. 

> 
> > Using the test program mentioned here, that allocates fixed sized
> > blocks till exhaustion:
> > https://www.linux-mips.org/archives/linux-mips/2011-05/msg00252.html,
> > no difference was noticed in the number of allocations. Most varied
> > from run to run, but were always within a few allocations of one
> > another between patched and un-patched runs.
> >
> > Performance Measurements:
> > Using strace with -T option and filtering for mmap on the program ls
> > shows a slowdown of approximate 3.7%
> 
> NAK.
> 
> It's just too costly. And no obvious benefits.

Sorry I used to have the explanation in the message, a carless edit
removed it.

The cost does suck, perhaps something like personality + KConfig option....

> 
> --
>  Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]