Re: stackguard-like embedded protection

["Bluefish (P.Magnusson)" <11a () GMX NET>]

> Obviously the version presented is NOT secure as stackguard.
> This want not be a stackguard replacement -- it's just an idea.

Uhmm..

Obviously, the current solution with only one variable won't be enough for
any real world example; but if hacked to use a 100.000 array or something
it would be possible to apply to most realworld examples [assuming you
don't use functions heavily dependant on recursion]

> As suggested by Alessandro Rubini there is also a problem
> with this approach: it seems directed to the programmer.
> The programmer should not think in terms of stack protection tricks,
> but in terms of good programming.

a minipatch could be created, alas if you temporarily are using a couple
of functions you are going to rewrite, this could do until then. I would
agree with Alessandro Rubini if we're talking about 'final' revisions. But
in alpha releases or betas with limited availability, this hack could be
usefull.

My greatest problem with this approach is that it may give a false sense
of security. Example:
  a() { b(); } is changed to a() { safe_enter; b(); safe_leave; }

To most readers, it would indicate a() to be secure, where as a() really
hasn't any control over what's happening - overflows or formatation bugs
in b() will allow attackers to modify return adress and supply malicious
code.

> Agreed at all, even if from the state of view of
> the redundancy this helps.
> So, sorry for this bad coding example.

I enjoyed the post. I like things to think on :)

..:::::::::::::::::::::::::::::::::::::::::::::::::..
     http://www.11a.nu || http://bluefish.11a.nu
    eleventh alliance development & security team