From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752565AbbBRD16 (ORCPT ); Tue, 17 Feb 2015 22:27:58 -0500 Received: from mail-ob0-f170.google.com ([209.85.214.170]:46193 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751618AbbBRD14 (ORCPT ); Tue, 17 Feb 2015 22:27:56 -0500 MIME-Version: 1.0 In-Reply-To: <54E257C0.9080304@amacapital.net> References: <20150214173350.GA18393@www.outflux.net> <54E257C0.9080304@amacapital.net> Date: Tue, 17 Feb 2015 19:27:55 -0800 X-Google-Sender-Auth: H7aBTCV6zoOORaoiaWEhfAOPG6o Message-ID: Subject: Re: [PATCH] ASLR: fix stack randomization on 64-bit systems From: Kees Cook To: Andy Lutomirski Cc: Andrew Morton , LKML , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , "x86@kernel.org" , Alexander Viro , Ismael Ripoll , Hector Marco-Gisbert , =?UTF-8?Q?Jan=2DSimon_M=C3=B6ller?= , "linux-fsdevel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 16, 2015 at 12:49 PM, Andy Lutomirski wrote: > On 02/14/2015 09:33 AM, Kees Cook wrote: >> >> From: Hector Marco-Gisbert >> >> 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