Bugtraq mailing list archives
Re: A way to prevent buffer overflow exploits?
From: peter.jeremy () AUSS2 ALCATEL COM AU (Peter Jeremy)
Date: Thu, 30 Jul 1998 07:49:53 +1000
On Thu, 30 Jul 1998 02:13:26 +1000, "John D. Hardin" <jhardin () WOLFENET COM> wrote:
On Tue, 28 Jul 1998, Cy Schubert wrote:What makes MVS (and VM) so impervious to attack is that the S/390 hardware doesn't rely on a stack, making effective buffer overruns considerably more difficult. (A little off topic :)
Re-entrant and recursive functions are also considerably more difficult:-(. (And the return address will still wind up in memory unless you're calling a leaf routine).
I wonder how feasible it would be to modify GCC to generate code with two stacks (or something equivalent): one for local variables, the other for parameters and return addresses.
How about FORTH :-)? A couple of problems: 1) Supporting a second stack efficiently would need kernel support (it could be emulated in a user-land signal handler but would be much more expensive). 2) Putting the parameters and return address on the same stack makes sense for SPARC (and other register-window architectures). For the x86 architecture, it makes more sense to put the parameters onto the variable stack (this leaves EBP for data and ESP for addresses). Overall, though, the benefits probably outweigh the costs.
Or how about allocating space for all local variables from the system heap automatically and transparently rather than placing them on the stack?
The hard part is freeing them again. Unwinding a stack is easy because it's LIFO. How do you work out which pieces of heap to free after you do a longjmp?
Or how about automatically allocating space just for local strings?
I'm not sure what this means. C has no concept of a `string'. Peter -- Peter Jeremy (VK2PJ) peter.jeremy () alcatel com au Alcatel Australia Limited 41 Mandible St Phone: +61 2 9690 5019 ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247
Current thread:
- Re: A way to prevent buffer overflow exploits? Peter Jeremy (Jul 29)