Re: stackguard-like embedded protection

[Crispin Cowan <crispin () WIREX COM>]

antirez wrote:

> I didn't use a limited number of recursion, nor an alternative stack.
> Just I store the old saved ret on the stack itself, but it is the last
> variable, so it's hard to overwrite. Also if foo() is vulnerable
> you can modify the address of saved f() RET, that's not so critical.

Excellent explanation.  Thanks for clarifying.


> Is this approach in your opinion too insecure?

Yes, IMHO, this method is insecure.  To attack the redundant RET value stored as the last
variable, I need to find an overflowable buffer in a function that is *called* by the
victim function, so that I can get below your check variable.

To make that work, I have actually *preserve* the return address in the function that
contains the overflow, but since that return address will be highly predictable for known
programs, this is not too hard.


> If I'm right in order to exploit this you need: two buffer overflows,
> one in f() and one in foo(), that's hard, and also the overflow of
> the nested function must allow you to overwrite a var before the buffer
> itself, i.e. you must overwrite with the buffer a pointer and so on.
> But maybe there is a clear and simple attack that I'm not considering.

You only need one overflow.  Suppose foo() calls bar(), and bar() has an overflowable
buffer a[].  I overflow the buffer a[] with a large string.  I craft my overflow so that
the variables and stack frame for bar() actually still work.  But I'm really aiming at
both the RET value and the check variable for function foo().


> Note that this kind of protection have some problem at least with
> -ffomit-frame-pointer option.

I don't *think* that frame pointers present a problem for my proposed attack.

Crispin

--
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution:                    http://immunix.org
                Olympics:  The Corruption Games