Subject: moving the stack randomly
To: None <tech-security@netbsd.org>
From: Michael C. Richardson <mcr@sandelman.ottawa.on.ca>
List: tech-security
Date: 12/31/1999 12:33:35
  by redmail.netbsd.org with SMTP; 31 Dec 1999 17:33:39 -0000
	by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id MAA10370
	for <tech-security@netbsd.org>; Fri, 31 Dec 1999 12:33:37 -0500 (EST)
Message-Id: <199912311733.MAA26959@istari.sandelman.ottawa.on.ca>
To: tech-security@netbsd.org
Subject: moving the stack randomly
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 31 Dec 1999 12:33:35 -0500
From: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>


  The following was posted to Ted T'so to linux-kernel. I tend to agree
with him. The technique of moving the bottom of the stack (in libc/ld.so)
a random amount seems like a very good one... very easy to do. 


http://www.progressive-comp.com/Lists/?l=linux-kernel&m=94661224428469&w=2 


List:     linux-kernel
Subject:  Re: Unexecutable Stack / Buffer Overflow Exploits...
From:     "Theodore Y. Ts'o" <tytso@MIT.EDU>
Date:     1999-12-31 3:42:49
[Download message RAW]

   Date: Thu, 30 Dec 1999 19:37:39 -0800 (PST)
   From: Dan Hollis <goemon@sasami.anime.net>

   Is there any reason we cant do the first 2 immediately?

   FWIW I thought solar designer patch did do the first one.

No, the Solar Designer patch arranges things so that the default
location of shared libraries is mapped in such that they contain a 0x00
in their address.  I'm suggestiong that we do the same with the stack.
This makes it a lot harder to change the return address to be a location
on the stack (although someone could still change the return address to
be anywhere else in the program text segment.)

(BTW, changing the location of the shared library is only marginally
useful.  As I pointed out in an earlier e-mail message, all you have to
do is find a location in the text segment which involves a call to execv
(or chmod, or some other other convenient library routine) and then
patch the return address of a stack frame to return to that call
instruction.)

                                                - Ted



http://www.progressive-comp.com/Lists/?l=linux-kernel&m=94661082127973&w=2 

List:     linux-kernel
Subject:  Re: Unexecutable Stack / Buffer Overflow Exploits...
From:     "Theodore Y. Ts'o" <tytso@MIT.EDU>
Date:     1999-12-31 3:24:51
[Download message RAW]

   Date: Thu, 30 Dec 1999 18:21:34 -0800 (PST)
   From: Dan Hollis <goemon@sasami.anime.net>

   Youre talking about stackguard right? I guess the problem here is that
   noone has ported stackguard to egcs yet. Would be nice though.

No, I wasn't talking just about stackguard; other techniques do exist:

        * arranging so that the stack pointer contains a 0x00 byte to
                make it harder for null-terminated strings to be used to
                write a valid return address

        * at program start time, randomly changing the starting point of
                the stack by a few hundred kilbytes.  (Since the starting
                location is changing randomly for every program
                invocation, guesses based on one process doesn't help
                eliminate possible guesses on another process.)

        * have libc do stack frame analysis, and then have certain
                functions (sprintf, memcpy, strcpy, etc.) not allow
                operations which overwrite stack frame boundaries.

Both stackguard and the last option requires some CPU overhead at
run-time; the first two don't require any overhead at all.  Note that
some of approaches, such as changing the stack location randomly will
stop certain attacks that the Solar Designer patch won't catch.

                                                - Ted

http://www.progressive-comp.com/Lists/?l=linux-kernel&m=94660821126937&w=2   

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Date: Thu, 30 Dec 1999 21:39:28 -0500
Subject: Re: Unexecutable Stack / Buffer Overflow Exploits...

   From: Steve VanDevender <stevev@efn.org>
   Date: Thu, 30 Dec 1999 17:58:09 -0800 (PST)

   1.  Most buffer overrun exploits are simple stack smashes that
   would be prevented by a nonexecutable stack.  Arguing that this
   would provide no real protection because it will force crackers
   to develop on other methods of attack is bogus, because you could
   make the same argument for almost any other built-in OS security
   protection, i.e.  restricting file permissions forces crackers to
   find ways to gain the privileges needed to write to the files
   they want, so restricting file permissions is only a temporary
   solution too by that logic.  The point is that something that was
   available and easily exploitable to bypass security is no longer
   available.

People keep making this argument, but it's not a valid one.

Look, making the stack non-executable purports to solve a generic class
of problems involving stack overruns.  The fact is, it doesn't.
Fundamentally, the real problem is the fact that the program allows an
automatic array variable to be overrun, and allow the stack to be
smashed.

Suppose an attacker find a stack overrun in sendmail and the stack is
executable; he just simply sends data which overwrites the return
location on the stack, and contains the code to run execv("/bin/sh").
If the stack is made non-executable, then all the attacker needs to do
is find some place in the sendmail text where the instruction "call
execv" lives.  He then overwrites the arguments area of the stack with
the desired arguments of execv, makes the return address point to the
"call execv" instruction, and then when the function returns, control is
transfered to the "call execv" instruction, which then in turn transfers
control to the execv code in libc, and we're off to the races.

So making the stack non-executable didn't stop the attack!  It changed
the method by which the attacker might need to exploit a stack smash,
but that's about it.  And once someone writes a tool to automatically
analyze a binary to find vulnerable places where a stack smashing attack
can transfer control into a victim program's text area, then any
advantage making the stack non-executable is well and truely gone.  At
best, making the stack non-executable is really only a
security-through-obsecurity kind of thing.  It will stop stupid
hackers.... temporarily.... until they adapt their methods to attack the
very same holes they are attacking today.

It's like putting antibiotics into chicken feed.  It might temporarily
decrease the spread of certain types of bacteria in improperly cooked
food, but in the long run, the bacteria develop resistance, and then
we're back where we're started.  And you'll notice that scientists have
made the argument that it's better not to put antibiotics in chicken
feed if it isn't going to stop the bacteria in the long run.  This is a
similar situation.

						- Ted

Please read the FAQ at http://www.tux.org/lkml/