[PATCH] this patch add a possibility to add a random offset to the stack on exec.

[PATCH] this patch add a possibility to add a random offset to the stack on exec.

[Evgeny Polyakov]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

Hello, linux-guru.

A couple of days ago Artur Grabovsky add this thing into the OpenBSD(
someone guess, this is the most secure OS) kernel.
This, as he suppose, not improve security of the system, but do OS more
strong to the script-kiddies attack.
Althought all admins and security analysist are loudly speaking, that
Linux is the greatest hole in security aspect, i think, that with straight
/dev/hands and not stupid /dav/brain the system can be unbreakable.
But there are situations, when even the best administrator cann't fight
against script-kiddies becouse of vendors, that cann't patch it's soft in
time.
And many systems lost it's defense.
In this cases many things can help, for example nonexecutable stack.
This patch also helps in manner of this kind.
If machine has random stack base in any exec, script kiddies will not
write _simple_ exploits, becouse of allmost such programs beleive, that
stack base remains the same.
And script kiddies should learn much more complex methods, like rewriting
dtors section and other.
In this case this patch cann't help, but i however belive, that this is
not bad.

At the and I want to cite OpenBSD developer, Artur Grabovsky:
"Add a possibility to add a random offset to the stack on exec. This makes
it slightly harder to write generic buffer overflows. This doesn't really
give any real security, but it raises the bar for script-kiddies and it's
really cheap."

Thank for your attention to this patch.

P.S. It also add one check to remove one XXX :)

P.P.S. And sorry for my english :)

P.P.P.S If i have sad trully delirium, then tell me it, becouse i am only
a beginner( or lamer).

---
WBR. //s0mbre

[-- Attachment #2: random_stack_base.patch --]
[-- Type: text/plain, Size: 2758 bytes --]

--- ../good_linux/fs/binfmt_aout.c	Sat Jul 21 23:42:25 2001
+++ ./fs/binfmt_aout.c	Thu Aug 23 05:24:34 2001
@@ -24,6 +24,7 @@
 #include <linux/binfmts.h>
 #include <linux/personality.h>
 #include <linux/init.h>
+#include <linux/random.h>
 
 #include <asm/system.h>
 #include <asm/uaccess.h>
@@ -195,8 +196,15 @@
 	unsigned long * sp;
 	int argc = bprm->argc;
 	int envc = bprm->envc;
-
-	sp = (unsigned long *) ((-(unsigned long)sizeof(char *)) & (unsigned long) p);
+	unsigned long rand;
+	
+	sp = (unsigned long *)
+			((-(unsigned long)sizeof(char *)) & (unsigned long) p );
+	
+	get_random_bytes(&rand, 4);
+	rand %= MAX_ARG_PAGES*PAGE_SIZE;
+	sp = (unsigned long *)((unsigned long)sp - rand);
+	
 #ifdef __sparc__
 	/* This imposes the proper stack alignment for a new process. */
 	sp = (unsigned long *) (((unsigned long) sp) & ~7);
@@ -411,9 +419,10 @@
 		send_sig(SIGKILL, current, 0); 
 		return retval;
 	}
-
+	
 	current->mm->start_stack =
 		(unsigned long) create_aout_tables((char *) bprm->p, bprm);
+
 #ifdef __alpha__
 	regs->gp = ex.a_gpvalue;
 #endif
--- ../good_linux/fs/binfmt_elf.c	Sat Jul 21 23:42:25 2001
+++ ./fs/binfmt_elf.c	Thu Aug 23 05:24:21 2001
@@ -31,6 +31,7 @@
 #include <linux/init.h>
 #include <linux/highuid.h>
 #include <linux/smp_lock.h>
+#include <linux/random.h>
 
 #include <asm/uaccess.h>
 #include <asm/param.h>
@@ -115,7 +116,8 @@
 	char *k_platform, *u_platform;
 	long hwcap;
 	size_t platform_len = 0;
-
+	unsigned long rand;
+	
 	/*
 	 * Get hold of platform and hardware capabilities masks for
 	 * the machine we are running on.  In some cases (Sparc), 
@@ -137,6 +139,11 @@
 	 * Force 16 byte _final_ alignment here for generality.
 	 */
 	sp = (elf_addr_t *)(~15UL & (unsigned long)(u_platform));
+	
+	get_random_bytes(&rand, 4);
+	rand %= MAX_ARG_PAGES*PAGE_SIZE;
+	sp = (unsigned long *)((unsigned long)sp - rand);
+					
 	csp = sp;
 	csp -= (1+DLINFO_ITEMS)*2 + (k_platform ? 2 : 0);
 #ifdef DLINFO_ARCH_ITEMS
@@ -413,7 +420,7 @@
 	struct elfhdr interp_elf_ex;
   	struct exec interp_ex;
 	char passed_fileno[6];
-
+	
 	/* Get the exec-header */
 	elf_ex = *((struct elfhdr *) bprm->buf);
 
@@ -592,9 +599,14 @@
 	/* Do this so that we can load the interpreter, if need be.  We will
 	   change some of these later */
 	current->mm->rss = 0;
-	setup_arg_pages(bprm); /* XXX: check error */
+	retval = setup_arg_pages(bprm);
+    if (retval < 0) {
+		/* Someone check-me: is this error path enough? */
+		send_sig(SIGKILL, current, 0);
+		return retval;
+	}
+	
 	current->mm->start_stack = bprm->p;
-
 	/* Now we do a little grungy work by mmaping the ELF image into
 	   the correct location in memory.  At this point, we assume that
 	   the image should be loaded at fixed address, not at a variable

Re: [PATCH] this patch add a possibility to add a random offset to the stack on exec.

[David Weinehall]

On Thu, Aug 23, 2001 at 05:32:10AM +0400, Evgeny Polyakov wrote:
> Hello, linux-guru.
> 
> A couple of days ago Artur Grabovsky add this thing into the OpenBSD(
> someone guess, this is the most secure OS) kernel.
> This, as he suppose, not improve security of the system, but do OS more
> strong to the script-kiddies attack.
> Althought all admins and security analysist are loudly speaking, that
> Linux is the greatest hole in security aspect, i think, that with straight
> /dev/hands and not stupid /dav/brain the system can be unbreakable.
> But there are situations, when even the best administrator cann't fight
> against script-kiddies becouse of vendors, that cann't patch it's soft in
> time.
> And many systems lost it's defense.
> In this cases many things can help, for example nonexecutable stack.
> This patch also helps in manner of this kind.
> If machine has random stack base in any exec, script kiddies will not
> write _simple_ exploits, becouse of allmost such programs beleive, that
> stack base remains the same.
> And script kiddies should learn much more complex methods, like rewriting
> dtors section and other.
> In this case this patch cann't help, but i however belive, that this is
> not bad.

Oh my $DEITY, not this discussion again.

Look, this kind of patches (non-executable stacks, etc.) surfaces
at least twice a year, causes a two-three weeks long discussion
(flame-war), then dies. Linus hasn't taken such a patch into the
kernel so far. Neither has Alan.

Let it rest, or contact Linus directly in about a week or two (when
he has returned from his vacation) and as him if he a.) has changed
his mind, and if so, b.) thinks your patch looks good.


/David Weinehall

PS: If I remember correctly, Theodore T'so is the person who was most
capable to shoot down this idea. Sorry if I'm wrong on that account.
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: [PATCH] this patch add a possibility to add a random offset to the stack on exec.

[Mark H. Wood]

It would be much more productive to create some sort of stupid-code
detector so we can know where to fix things.  For example, hacking gcc to
offer warnings on any reference to 'auto' storage by I/O or ASCIZ string
functions, similar to that warning that ld throws when you use gets().

( I know that the nonexecutable stack patch has been shot down many times
as a security measure, but it *would* be a decent stupid-code detector
when combined with an exploit attempt.  Knowing that program X attempted
to aid and abet a burglar is better than expecting someone to comb through
every line of code on the 'net on the chance that holes will be found.
The burglars already do the latter, so why not put them to work detecting
bugs for us? :-} )

-- 
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Make a good day.

Re: [PATCH] this patch add a possibility to add a random offset to the stack on exec.

[Alan Cox]

> "Add a possibility to add a random offset to the stack on exec. This makes
> it slightly harder to write generic buffer overflows. This doesn't really
> give any real security, but it raises the bar for script-kiddies and it's
> really cheap."

Its so slight its useless, and the randomness makes it hard to verify you
fixed a problem. Remember once an exploit appears a box will get scanned
hundreds of times - someone will get the right offset 8)

There is another good reason for offseting stacks within the page -
especially the kernel stacks which is to avoid things like each apache
task sleeping with wait queues on the same cache colour

Re: [PATCH] this patch add a possibility to add a random offset to the stack on exec.

[Evgeny Polyakov]

Hello.

On Thu, 23 Aug 2001 13:47:31 +0100 (BST)
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>> "Add a possibility to add a random offset to the stack on exec. This
makes
>> it slightly harder to write generic buffer overflows. This doesn't
really
>> give any real security, but it raises the bar for script-kiddies and
it's
>> really cheap."

AC> Its so slight its useless, and the randomness makes it hard to verify
AC> you
AC> fixed a problem. Remember once an exploit appears a box will get
scanned
AC> hundreds of times - someone will get the right offset 8)

You want to tell, that running 2 process one directky after another( like
exploits do),
and esp will be the same, even with random addition? It's impossible.

But i quite understand your position in this question :(.

AC> There is another good reason for offseting stacks within the page -
AC> especially the kernel stacks which is to avoid things like each apache
AC> task sleeping with wait queues on the same cache colour

---
WBR. //s0mbre