Re: RFC: stack/heap collision vulnerability and mitigation with GCC

[Florian Weimer <fw@deneb.enyo.de>]

* Richard Earnshaw:

> I can't help but feel there's a bit of a goode olde mediaeval witch hunt
> going on here.  As Wilco points out, we can never defend against a
> function that is built without probe operations but skips the entire
> guard zone.  The only defence there is a larger guard zone, but how big
> do you make it?

Right.  And in the exploitable cases we have seen, there is a
dynamically sized allocation which the attacker can influence, so it
seems fairly likely that in a partially hardended binary, there could
be another call stack which is exploitable, with a non-hardened
function at the top.

I think a probing scheme which assumes that if the caller moves the
stack pointer into more than half of the guard area, that's the
callers fault would be totally appropriate in practice.  If possible,
callee-only probing for its own stack usage is preferable, but not if
it means instrumenting all functions which use the stack.

> Yes, you'd need a system recompile to deploy it in full, but even a
> fairly limited rebuild of critical libraries (libc, libstdc++) would
> help.

And we'd be mostly interested in protecting dynamically sized stack
allocations anyway, and perhaps the occasional BUFSIZ and PATH_MAX
rrays.