Re: [PATCH v3 0/4] Allow customizable random offset to mmap_base address.

[Andrew Morton]

On Wed, 18 Nov 2015 15:20:04 -0800 Daniel Cashman <dcashman@xxxxxxxxxxx> wrote:

> Address Space Layout Randomization (ASLR) provides a barrier to
> exploitation of user-space processes in the presence of security
> vulnerabilities by making it more difficult to find desired code/data
> which could help an attack.  This is done by adding a random offset to the
> location of regions in the process address space, with a greater range of
> potential offset values corresponding to better protection/a larger
> search-space for brute force, but also to greater potential for
> fragmentation.
> 
> The offset added to the mmap_base address, which provides the basis for
> the majority of the mappings for a process, is set once on process exec in
> arch_pick_mmap_layout() and is done via hard-coded per-arch values, which
> reflect, hopefully, the best compromise for all systems.  The trade-off
> between increased entropy in the offset value generation and the
> corresponding increased variability in address space fragmentation is not
> absolute, however, and some platforms may tolerate higher amounts of
> entropy.  This patch introduces both new Kconfig values and a sysctl
> interface which may be used to change the amount of entropy used for
> offset generation on a system.
> 
> The direct motivation for this change was in response to the
> libstagefright vulnerabilities that affected Android, specifically to
> information provided by Google's project zero at:
> 
> http://googleprojectzero.blogspot.com/2015/09/stagefrightened.html
> 
> The attack presented therein, by Google's project zero, specifically
> targeted the limited randomness used to generate the offset added to the
> mmap_base address in order to craft a brute-force-based attack. 
> Concretely, the attack was against the mediaserver process, which was
> limited to respawning every 5 seconds, on an arm device.  The hard-coded 8
> bits used resulted in an average expected success rate of defeating the
> mmap ASLR after just over 10 minutes (128 tries at 5 seconds a piece). 
> With this patch, and an accompanying increase in the entropy value to 16
> bits, the same attack would take an average expected time of over 45 hours
> (32768 tries), which makes it both less feasible and more likely to be
> noticed.
> 
> The introduced Kconfig and sysctl options are limited by per-arch minimum
> and maximum values, the minimum of which was chosen to match the current
> hard-coded value and the maximum of which was chosen so as to give the
> greatest flexibility without generating an invalid mmap_base address,
> generally a 3-4 bits less than the number of bits in the user-space
> accessible virtual address space.
> 
> When decided whether or not to change the default value, a system
> developer should consider that mmap_base address could be placed anywhere
> up to 2^(value) bits away from the non-randomized location, which would
> introduce variable-sized areas above and below the mmap_base address such
> that the maximum vm_area_struct size may be reduced, preventing very large
> allocations. 

Nice, thanks.

mips, powerpc and s390 also implement arch_mmap_rnd().  Are there any
special considerations here, or it just a matter of maintainers wiring
it up and testing it?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/