| |||||||||||||
Security-improving technologies which could be deployed nowSecurity-improving technologies which could be deployed nowPosted Oct 14, 2004 22:01 UTC (Thu) by iabervon (subscriber, #722)Parent article: Security-improving technologies which could be deployed now
One thing that I liked about HP/UX is that the stack grows up, which means that your stack buffer overflows tend to go into unused memory (and be easy to catch with debugging tools). Would there be any problem with making the stack grow in the opposite direction (assuming that you rebuilt everything that way)? It might even be possible to have the stack grow the normal way in executables which use the normal dynamic linker and switch to a different stack for library code.
(Log in to post comments)
Security-improving technologies which could be deployed now Posted Oct 15, 2004 6:41 UTC (Fri) by eru (subscriber, #2753) [Link] Would there be any problem with making the stack grow in the opposite directionThe direction the stack grows is usually fixed by the processor architecture, at least in all CISC-style processors. For example in the x86 family there are several common instructions that automaticlly push data to the stack or pop it. Making the stack grow in "unnatural" direction would require somehow working around their behaviour. Maybe you could do it but it certainly would impact performance and introduce extra complexity.
Security-improving technologies which could be deployed now Posted Jul 4, 2006 23:14 UTC (Tue) by bluefoxicy (guest, #25366) [Link] So after a couple years I finally figured this one out. The stack grows up, that's fine; when strcpy() or friends are called, your buffer overflows into strcpy()'s stack frame, and then strcpy() returns to your attack code.
In other words, stack-grows-up architectures aren't any more resistant to buffer overflows (ok so if they overflow in the same function, i.e. via a for loop, then they're safe; this is almost never what happens).
|
|||||||||||||