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: <20080206134959.GA25689@elte.hu>
Date:	Wed, 6 Feb 2008 14:49:59 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Hugh Dickins <hugh@...itas.com>, Pavel Machek <pavel@....cz>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ASLR: add possibility for more fine-grained
	tweaking


* Jiri Kosina <jkosina@...e.cz> wrote:

> ASLR: add possibility for more fine-grained tweaking
> 
> Some prehistoric binaries don't like when start of brk area is located 
> anywhere else than just after code+bss.
> 
> This patch adds possibility to configure the default behavior of 
> address space randomization. In addition to that, randomize_va_space 
> now can have value of '2', which means full randomization including 
> brk space.

i've already added the patch below to x86.git.

	Ingo

-------------------->
Subject: brk randomization: introduce CONFIG_COMPAT_BRK
From: Ingo Molnar <mingo@...e.hu>

based on similar patch from: Pavel Machek <pavel@....cz>

Introduce CONFIG_COMPAT_BRK. If disabled then the kernel is free
(but not obliged to) randomize the brk area.

Heap randomization breaks ancient binaries, so we keep COMPAT_BRK
enabled by default.

Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 fs/binfmt_elf.c |    2 +-
 init/Kconfig    |   12 ++++++++++++
 mm/memory.c     |   13 ++++++++++++-
 3 files changed, 25 insertions(+), 2 deletions(-)

Index: linux-x86.q/fs/binfmt_elf.c
===================================================================
--- linux-x86.q.orig/fs/binfmt_elf.c
+++ linux-x86.q/fs/binfmt_elf.c
@@ -1077,7 +1077,7 @@ static int load_elf_binary(struct linux_
 	current->mm->start_stack = bprm->p;
 
 #ifdef arch_randomize_brk
-	if (current->flags & PF_RANDOMIZE)
+	if ((current->flags & PF_RANDOMIZE) && (randomize_va_space > 1))
 		current->mm->brk = current->mm->start_brk =
 			arch_randomize_brk(current->mm);
 #endif
Index: linux-x86.q/init/Kconfig
===================================================================
--- linux-x86.q.orig/init/Kconfig
+++ linux-x86.q/init/Kconfig
@@ -541,6 +541,18 @@ config ELF_CORE
 	help
 	  Enable support for generating core dumps. Disabling saves about 4k.
 
+config COMPAT_BRK
+	bool "Disable heap randomization"
+	default y
+	help
+	  Randomizing heap placement makes heap exploits harder, but it
+	  also breaks ancient binaries (including anything libc5 based).
+	  This option changes the bootup default to heap randomization
+	  disabled, and can be overriden runtime by setting
+	  /proc/sys/kernel/randomize_va_space to 2.
+
+	  On non-ancient distros (post-2000 ones) Y is usually a safe choice.
+
 config BASE_FULL
 	default y
 	bool "Enable full-sized data structures for core" if EMBEDDED
Index: linux-x86.q/mm/memory.c
===================================================================
--- linux-x86.q.orig/mm/memory.c
+++ linux-x86.q/mm/memory.c
@@ -82,7 +82,18 @@ void * high_memory;
 EXPORT_SYMBOL(num_physpages);
 EXPORT_SYMBOL(high_memory);
 
-int randomize_va_space __read_mostly = 1;
+/*
+ * Randomize the address space (stacks, mmaps, brk, etc.).
+ *
+ * ( When CONFIG_COMPAT_BRK=y we exclude brk from randomization,
+ *   as ancient (libc5 based) binaries can segfault. )
+ */
+int randomize_va_space __read_mostly =
+#ifdef CONFIG_COMPAT_BRK
+					1;
+#else
+					2;
+#endif
 
 static int __init disable_randmaps(char *s)
 {
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ