At 09:13 AM 7/29/98 -0700, John D. Hardin wrote: >Might moving the local variables away >from the return addresses this way be a relatively cheap way to prevent >buffer overflow exploits without having to recode all of the applications >or using expensive bounds-checking? It would be a great start, though it certainly wouldn't be foolproof. (If the program under attack interprets commands, for example, it's still possible to overflow the variable into a buffer that holds commands to be executed. Then all you need to do is plant a dangerous command, or one that lets you into the system. Still, because hammering the subroutine return stack is such an easy thing to exploit, it'd be worth preventing it. Incidentally, some embedded compilers do a variation on the concept of a separate stack. They allocate parameters and locals as globals in the program's global data area, then use lifetime and program flow analysis to determine when the space can be re-used by another routine. Since accesses to the global data segment require shorter opcodes than access to the stack, this crunches the program size AND can make the code run faster. >Or how about allocating space for all local variables from the system heap >automatically and transparently rather than placing them on the stack? Heaps are slow, unfortunately. >Or how about automatically allocating space just for local strings? This >would take care of buffer overflows with minimal impact, wouldn't it? Yes, but again, this might slow things down. The global approach would be better. >Granted, fixing the applications is the better long-term solution, but >these might be ways to buy time to do the auditing and correction. Agreed. --Brett
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:10:30 PDT