linux-kernel - Re: [PATCH] ASLR: fix stack randomization on 64-bit systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGXu5jL=DL=k7AAcJjg5Gci3vmCzO2t50+E_3eXuOt6tM0Wp1Q@mail.gmail.com>
Date:	Tue, 17 Feb 2015 19:27:55 -0800
From:	Kees Cook <keescook@...omium.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"x86@...nel.org" <x86@...nel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Ismael Ripoll <iripoll@....es>,
	Hector Marco-Gisbert <hecmargi@....es>,
	Jan-Simon Möller <dl9pf@....de>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH] ASLR: fix stack randomization on 64-bit systems

On Mon, Feb 16, 2015 at 12:49 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On 02/14/2015 09:33 AM, Kees Cook wrote:
>>
>> From: Hector Marco-Gisbert <hecmargi@....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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/