Re: [PATCH] ASLR: fix stack randomization on 64-bit systems
* Borislav Petkov wrote: > On Wed, Feb 18, 2015 at 09:19:01PM +0100, Ingo Molnar wrote: > > Absolutely, this is x86/urgent material, so no need to wait for -rc1 > > with it. > > Right, so I can start shuffling stuff to you tomorrow, > this patch is in one of the pull requests. I can drop it > too if preferred. I'll let you guys decide. Tomorrow is fine to me. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASLR: fix stack randomization on 64-bit systems
On Wed, Feb 18, 2015 at 09:19:01PM +0100, Ingo Molnar wrote: > Absolutely, this is x86/urgent material, so no need to wait for -rc1 > with it. Right, so I can start shuffling stuff to you tomorrow, this patch is in one of the pull requests. I can drop it too if preferred. I'll let you guys decide. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASLR: fix stack randomization on 64-bit systems
* Andrew Morton wrote: > On Wed, 18 Feb 2015 10:15:43 +0100 Borislav Petkov wrote: > > > CVE-2015-1593 > > > > > > Signed-off-by: Hector Marco-Gisbert > > > Signed-off-by: Ismael Ripoll > > > [kees: rebase, fix 80 char, clean up commit message, add test example, > > > cve] > > > Signed-off-by: Kees Cook > > > Cc: sta...@vger.kernel.org > > > > Ok, I'm picking this up. Do scream if someone else wants to do that, > > I grabbed it, but shall drop my copy if it turns up in linux-next. > > > otherwise it is going to tip next week, after the merge window is over. > > It's tagged for -stable backporting, so it should go into 3.20? Absolutely, this is x86/urgent material, so no need to wait for -rc1 with it. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASLR: fix stack randomization on 64-bit systems
On Wed, 18 Feb 2015 10:15:43 +0100 Borislav Petkov wrote: > > CVE-2015-1593 > > > > Signed-off-by: Hector Marco-Gisbert > > Signed-off-by: Ismael Ripoll > > [kees: rebase, fix 80 char, clean up commit message, add test example, cve] > > Signed-off-by: Kees Cook > > Cc: sta...@vger.kernel.org > > Ok, I'm picking this up. Do scream if someone else wants to do that, I grabbed it, but shall drop my copy if it turns up in linux-next. > otherwise it is going to tip next week, after the merge window is over. It's tagged for -stable backporting, so it should go into 3.20? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASLR: fix stack randomization on 64-bit systems
On Sat, Feb 14, 2015 at 09:33:50AM -0800, 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 > 0x3f 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 00:00 0 > [stack] > 7fff5a332000-7fff5a353000 rw-p 00:00 0 > [stack] > 7ffcdb7a1000-7ffcdb7c2000 rw-p 00:00 0 > [stack] > 7ffd5e2c4000-7ffd5e2e5000 rw-p 00:00 0 > [stack] > ... > > Once corrected, the leading bytes should be between 7ffc and 7fff, rather > than always being 7fff. > > CVE-2015-1593 > > Signed-off-by: Hector Marco-Gisbert > Signed-off-by: Ismael Ripoll > [kees: rebase, fix 80 char, clean up commit message, add test example, cve] > Signed-off-by: Kees Cook > Cc: sta...@vger.kernel.org Ok, I'm picking this up. Do scream if someone else wants to do that, otherwise it is going to tip next week, after the merge window is over. Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASLR: fix stack randomization on 64-bit systems
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 >> 0x3f 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 00:00 0 >> [stack] >> 7fff5a332000-7fff5a353000 rw-p 00:00 0 >> [stack] >> 7ffcdb7a1000-7ffcdb7c2000 rw-p 00:00 0 >> [stack] >> 7ffd5e2c4000-7ffd5e2e5000 rw-p 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASLR: fix stack randomization on 64-bit systems
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 0x3f 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 00:00 0 [stack] 7fff5a332000-7fff5a353000 rw-p 00:00 0 [stack] 7ffcdb7a1000-7ffcdb7c2000 rw-p 00:00 0 [stack] 7ffd5e2c4000-7ffd5e2e5000 rw-p 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? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASLR: fix stack randomization on 64-bit systems
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 0x3f 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 00:00 0 [stack] 7fff5a332000-7fff5a353000 rw-p 00:00 0 [stack] 7ffcdb7a1000-7ffcdb7c2000 rw-p 00:00 0 [stack] 7ffd5e2c4000-7ffd5e2e5000 rw-p 00:00 0 [stack] ... Once corrected, the leading bytes should be between 7ffc and 7fff, rather than always being 7fff. CVE-2015-1593 Signed-off-by: Hector Marco-Gisbert Signed-off-by: Ismael Ripoll [kees: rebase, fix 80 char, clean up commit message, add test example, cve] Signed-off-by: Kees Cook Cc: sta...@vger.kernel.org --- arch/x86/mm/mmap.c | 6 +++--- fs/binfmt_elf.c| 5 +++-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c index 919b91205cd4..df4552bd239e 100644 --- a/arch/x86/mm/mmap.c +++ b/arch/x86/mm/mmap.c @@ -35,12 +35,12 @@ struct va_alignment __read_mostly va_align = { .flags = -1, }; -static unsigned int stack_maxrandom_size(void) +static unsigned long stack_maxrandom_size(void) { - unsigned int max = 0; + unsigned long max = 0; if ((current->flags & PF_RANDOMIZE) && !(current->personality & ADDR_NO_RANDOMIZE)) { - max = ((-1U) & STACK_RND_MASK) << PAGE_SHIFT; + max = ((-1UL) & STACK_RND_MASK) << PAGE_SHIFT; } return max; diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 02b16910f4c9..995986b8e36b 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -645,11 +645,12 @@ out: static unsigned long randomize_stack_top(unsigned long stack_top) { - unsigned int random_variable = 0; + unsigned long random_variable = 0; if ((current->flags & PF_RANDOMIZE) && !(current->personality & ADDR_NO_RANDOMIZE)) { - random_variable = get_random_int() & STACK_RND_MASK; + random_variable = (unsigned long) get_random_int(); + random_variable &= STACK_RND_MASK; random_variable <<= PAGE_SHIFT; } #ifdef CONFIG_STACK_GROWSUP -- 1.9.1 -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/