4 ms·
Wikipedia is wrong. It is not naive. Yes, this does not solve every possible stack overwrite. But look at the number that have actually happened in the field a
by jblow 11y ago
Wikipedia is wrong. It is not naive.
Yes, this does not solve every possible stack overwrite. But look at the number that have actually happened in the field and whether this would have dramatically reduced vulnerability in those actual real-world cases. Most times it would.
Most notably, for overwrites happening within the local stack frame, you completely remove the possibility of overwriting the return address. This is a fundamental difference in the level of vulnerability of that kind of code.
It's called "reducing the attack surface". Well-known idea.
Maybe my post was a bit hyperbolic, but I chalk that up to being so annoyed at this.
- tptacek 11y agoIsn't the test case he just gave you a slightly obscured version of the canonical stack overflow? void dumb_func(char *user_input) { char buf[64]; sprintf(buf, "reformatted: %s", user_input); } Overflows in functions whose activation records precede the buffer are --- obviously, because they necessarily involve hand-rolled copy loops --- rarer than those that don't. Additional fun fact: a few early generations of mid-90s stack overflow exploits didn't even target the activation records at all! I think it's interesting and worthwhile to consider whether stacks growing upwards would have made exploit development meaningfully harder, but I also think the answer to that question is straightforward: no, not really.