* 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.
