lkml.org 
[lkml]   [2015]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH] ASLR: fix stack randomization on 64-bit systems
From
On Mon, Feb 16, 2015 at 12:49 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On 02/14/2015 09:33 AM, Kees Cook wrote:
>>
>> From: Hector Marco-Gisbert <hecmargi@upv.es>
>>
>> The issue is that the stack for processes is not properly randomized on 64
>> bit
>> architectures due to an integer overflow.
>>
>> The affected function is randomize_stack_top() in file "fs/binfmt_elf.c":
>>
>> static unsigned long randomize_stack_top(unsigned long stack_top)
>> {
>> unsigned int random_variable = 0;
>>
>> if ((current->flags & PF_RANDOMIZE) &&
>> !(current->personality & ADDR_NO_RANDOMIZE)) {
>> random_variable = get_random_int() & STACK_RND_MASK;
>> random_variable <<= PAGE_SHIFT;
>> }
>> return PAGE_ALIGN(stack_top) + random_variable;
>> return PAGE_ALIGN(stack_top) - random_variable;
>> }
>>
>> Note that, it declares the "random_variable" variable as "unsigned int".
>> Since
>> the result of the shifting operation between STACK_RND_MASK (which is
>> 0x3fffff on x86_64, 22 bits) and PAGE_SHIFT (which is 12 on x86_64):
>>
>> random_variable <<= PAGE_SHIFT;
>>
>> then the two leftmost bits are dropped when storing the result in the
>> "random_variable". This variable shall be at least 34 bits long to hold
>> the
>> (22+12) result.
>>
>> These two dropped bits have an impact on the entropy of process stack.
>> Concretely, the total stack entropy is reduced by four: from 2^28 to 2^30
>> (One
>> fourth of expected entropy).
>>
>> This patch restores back the entropy by correcting the types involved in
>> the
>> operations in the functions randomize_stack_top() and
>> stack_maxrandom_size().
>>
>> The successful fix can be tested with:
>> $ for i in `seq 1 10`; do cat /proc/self/maps | grep stack; done
>> 7ffeda566000-7ffeda587000 rw-p 00000000 00:00 0
>> [stack]
>> 7fff5a332000-7fff5a353000 rw-p 00000000 00:00 0
>> [stack]
>> 7ffcdb7a1000-7ffcdb7c2000 rw-p 00000000 00:00 0
>> [stack]
>> 7ffd5e2c4000-7ffd5e2e5000 rw-p 00000000 00:00 0
>> [stack]
>> ...
>>
>> Once corrected, the leading bytes should be between 7ffc and 7fff, rather
>> than always being 7fff.
>>
>> CVE-2015-1593
>
>
> Awesome. So the vdso randomization *and* the stack randomization
> implementations were buggy. Anyone want to check the mmap and brk
> randomization implementations?

Both appear to use randomize_range() ... which, after looking at it,
is buggy. But we've just not hit it yet. It uses get_random_int() but
is modulo an unsigned long. If anything were ever to call it with a
range > MAX_INT, it would truncate...

-Kees

>
> --Andy



--
Kees Cook
Chrome OS Security


\
 
 \ /
  Last update: 2015-02-18 04:41    [W:0.068 / U:1.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site