Date: Fri, 14 Feb 1997 19:39:11 +0100 From: Eivind Eklund <eivind@dimaga.com> To: Robin Melville <robmel@innotts.co.uk> Cc: Stephen McKay <syssgm@devetir.qld.gov.au>, Charles Mott <cmott@srv.net>, freebsd-chat@freebsd.org, syssgm@devetir.qld.gov.au Subject: Re: Trying to understand stack overflow Message-ID: <3.0.32.19970214193910.00a034c0@dimaga.com>
next in thread | raw e-mail | index | archive | help
At 07:32 AM 2/14/97 +0000, Robin Melville wrote:
>At 2:48 pm +1000 14/2/97, Stephen McKay wrote:
>
>> [lots of useful background snipped...]
>
>>If you carefully manipulate the return address you can run code from the
^^^^^^^^^
>>same array you overflowed.
Not necessary. You can do it with utter lack of care and just overflow a
_LOT_ with NOPs. (You need to get the address correct within a couple of
kilobytes, but usually that is no problem.) There was a description of the
technique just a couple of days ago either on -security or on BugTraq.
>In other words executing code within the stack frame. Can't the 386 MMU
restrict execution to the Text page? That would solve the whole thing.
Yes. This is not feasible due to GCC using trampolines (code generated on
the stack, on the fly) for implementing local functions and exceptions.
Also, due to the way memory-executableness is implemented on the
x86-series, there is (heresay coming up) a serious slowdown involved.
>>The real problem here is lack of bounds checking on memory objects. I
>>remember Dennis Ritchie (hmm, or was it Ken T?) claim that he had modified
>>his system C compiler so that every C pointer implied length as well as
>>starting location. Thus, every pointer and array access could be checked
>>for illegitimate accesses. The penalty is doubling the size of every
pointer
>>plus a run time checking cost. Given the dramas people are having with
>>security nowadays, and the plummeting cost of RAM and CPU power, I think
>>such an option should be added to GCC with all speed.
>
>This would also add enormously to the stability of C applications. Memory
>leakage is the bugbear of everything written in C.
This does not address memory-leakage - it address buffer overruns. For
memory leakage I would suggest Boehms garbage collector - it is in the
ports collection.
>I second the proposition wholeheartedly!
GCC+bounds checking have been available for about 2 years. For some reason
it hasn't made it into the standard GCC distribution (or hadn't, the last
time I looked). The latest set of patches are for 2.7.2 - I would guess
applying them to 2.7.2.1 shouldn't be too difficult.
[Home page for GCC with bounds-checking]
http://www-dse.doc.ic.ac.uk/~rj3/bounds-checking.html
[Release-directory for GCC with bounds-checking]
ftp://dse.doc.ic.ac.uk/pub/misc/bcc
Eivind Eklund perhaps@yes.no http://maybe.yes.no/perhaps/
eivind@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19970214193910.00a034c0>