Date: Thu, 13 Feb 1997 22:25:29 -0700 (MST) From: Charles Mott <cmott@srv.net> To: Stephen McKay <syssgm@devetir.qld.gov.au> Cc: freebsd-chat@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: Trying to understand stack overflow Message-ID: <Pine.BSF.3.91.970213220734.7180A-100000@darkstar> In-Reply-To: <199702140448.OAA27909@ogre.devetir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> Now, if one of those local variables is an array that you can overflow,
> the stuff that will get overwritten includes all the local variables with
> higher addresses plus the saved frame pointer plus the return address.
> If you carefully manipulate the return address you can run code from the
^^^^^^^^^^^^^^^^^^^^
This is the part that puzzles me. It seems that the stack data can have
an address which is not predictable beforehand (or is it?).
If the addresses within a process space are predictable, then possibly
there might be something that could be done (either in linking or
compiling) to make them a little less predictable from build to build (or
even run to run). Users could do a "make world STACK_RANDOMIZE=yes".
It seems the easiest way to do this to make the base address of the stack
memory segment unpredictable and somehow not alter the actual compiler too
much.
With this scheme, every build (or possible every executable instance)
would require different hack to get at it. Users logged into the system
might be able to infer the correct address offset, but external attacks
would require quite a bit of trial and error.
If there is some basic concept that I am still missing, please let me
know.
Charles Mott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.970213220734.7180A-100000>