Re: Easily and Permanently prevent all stack buffer overflows

On Fri, 16 Nov 2007 04:12:53 -0800, Abut wrote:

On Nov 14, 4:31 am, Wayne <nos...@xxxxxxxxxxxxxx> wrote:
I've often wondered why Linux (or any OS) puts up with
stack buffer overflows. They only happen because
the stack grows in one direction and buffers grow
in the other:

+----------------------------------------------------+
| unused stack space | buf | ... | return_addr | ... |
+----------------------------------------------------+
Lower memory address ----> Higher memory address

where buf is some local char array. A buffer
overflow (in the case, there are heap attacks too)
is only possible if a user over-writes the return
address or some other part of the "lower" stack
contents.

So why doesn't any OS define the stack growth in the
other direction:

+----------------------------------------------------+
| ... | return_addr | ... | buf | unused stack space |
+----------------------------------------------------+
Lower memory address ----> Higher memory address


-Wayne

Surely this is a function of the x86 architecture? PUSH is defined to
write the PUSHed register to the address pointed to by the stack
pointer, and then to *decrement* the stack pointer. POP reads from the
pointed-to address, and *increments* the stack pointer.
I don't see how any OS could realistically do it any differently on
that architecture - but perhaps I am missing something?

You're not missing something -- you're right. The entity that defines the
instruction set architecture specifies the calling conventions for
subroutines, including use of the stack for local variables, parameter
passing and return address. The compiler developer must follow the
specification (if not, different compilers won't interoperate). The OS
comes along well after (esp. Linux) and has no say. (In the distant past,
compiler and OS and ISA were co-developed by the same entity, as in the
case of the DEC VAX. I don't know of a recent example. Actually, there
haven't been too many new ISA's coming along lately.)
.

Relevant Pages

  • [0xbadc0ded #04] smtp.proxy <= 1.1.3
    ... A remotely exploitable format string vulnerability exists in smtp.proxy ... Since the 'line' buffer is ... Since smtp.proxy is started from a superserver, like inetd, the stack ... To determine the address of a function pointer we could either try to ...
    (Bugtraq)
  • [Full-Disclosure] [0xbadc0ded #04] smtp.proxy <= 1.1.3
    ... A remotely exploitable format string vulnerability exists in smtp.proxy ... Since the 'line' buffer is ... Since smtp.proxy is started from a superserver, like inetd, the stack ... To determine the address of a function pointer we could either try to ...
    (Full-Disclosure)
  • Re: App does not shut down on exiting the db
    ... ByVal or ByRef is only applicable to the argument and that value is always push on the stack, there is no buffer directly involved in that process, so if there is a problem of memory, technically, that would be a stack overflow, rather than a buffer overflow. ... is like the creation of a 32 bit pointer on the stack, initialized with the value of an existing 32 bit pointer in the calling procedure. ...
    (microsoft.public.access.modulesdaovba)
  • Re: The coming death of all RISC chips.
    ... different area of memory than the "stack", ... Any arbitrarily indirect pointer to code that can be ... overwritten by a buffer overflow is a potential hole (and an actual ... ways to exploit buffer overflows. ...
    (comp.arch)
  • Re: Buffer Over-runs, was Open source firewalls
    ... > pointer to the systemlibrary function. ... anybody who thinks that the non-executable stack gives ... > shared libraries tend to be loaded." ... gcc level tricks to prevent buffer overflows are widely in use nowadays ...
    (Linux-Kernel)