Re: Rep:Rep:Re: Rep:Re: [f-cpu] Stack handling

[Michael Riepe <michael@stud.uni-hannover.de>]

On Wed, Jul 24, 2002 at 08:29:55AM -0700, jaap stolk wrote:
[...]
> I might be missing the point here, but why can’t we
> just check the input of a program ? (like everybody
> used to do in basic)
> Is it so hard to check the size of something before
> its put into a buffer ?

Ask a programmer. Most of them refuse to (or are not aware of the
problem at all).

> As far as i can see, this is more a problem coused by
> a programmer / compiler that doesn’t check un-thruster
> input data, and not a CPU “security” problem.

If a program is insecure, it usually is the programmer's fault.

> Even when using separate code and data stack, a
> buffer overflow still course corrupted data, I can
> hardly call that “secure”, and corrupted data is
> very likely to crash the program anyway :-) 

Both are equally dangerous if pointers to code are involved (e.g. a
pointer to a function): overwrite them and you're able to inject and
execute your own (malicious) code. A separate return stack helps with
some cases, but it's no guarantee. Neither is a non-executable stack.

Keeping the return address and other `code' pointers in registers is
relatively safe - until the registers are saved to memory. Since this
will happen sooner or later, C programmers always have to check array
bounds, and avoid inherently unsafe functions like gets() or getwd().

On the other hand, F-CPU code can be less vulnerable to stack smashing
than e.g. Intel (ia32) code, mostly because function arguments and return
addresses are not by default stored in a memory-based stack.

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/