Re: A way to prevent buffer overflow exploits?

[peter.jeremy () AUSS2 ALCATEL COM AU (Peter Jeremy)]

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