Re: Easily and Permanently prevent all stack buffer overflows

Wayne wrote:
xi4oyu wrote:

On 11 14 , 12 31 , 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

The worst that can happen if a user overflows "buf"
is to over-write other local variables in the current
stack frame (not shown in the ASCII art), or write
to unused stack space.

I do realize both the OS and all apps would need to be
re-compiled to run on the new system, but that sort of
flash-cutover happened before. (IIRC early SunOS was
little-endian in one version and big-endian in the next.
Or maybe it's the other way around.)

But I've never seen this idea mentioned in ANY discussion
of buffer overflows. I can't be the first to think of
this simple idea, it seems obvious. So why isn't
this done? What am I (clearly a non-expert) missing?
Does anyone have any ideas?

-Wayne

Stack and Heap are orgnized in this ways cos we wanna save space for
the process



Thanks for the reply. But I don't understand how the direction
of stack growth affects the amount of memory consumed by a
process (actually a thread). The stack is fixed in size
at process creation time, and unlike the heap, doesn't grow
over time. "Stack growth" is really just "stack use", right?
So how does the direction affect total memory usage?

-Wayne


Please get a book on Linux memory management, and read it.

My suggestion is 'Understanding the Linux Kernel'. You can
Google for it.

The demand-paged virtual memory system of Linux will detect
an overflow of a memory section. It also uses only the active
pages of the memory sections in real memory.

Most of the overflow attacks are using buffers allocated
*in the stack*, so the memory management cannot detect an
overflow. This is simply sloppy programming.

--

Tauno Voipio
tauno voipio (at) iki fi
.

Relevant Pages

  • Re: Unchecked Buffer
    ... >where Windows allows a VIRUS can inject itself in the stack stack and the ... Additionally not all buffer overruns are quite this simple to spot. ... If UNICODE is defined then this is an overflow because sizeofwill ...
    (microsoft.public.security)
  • Re: Unchecked Buffer
    ... If you are referring to the "Buffer Overflow" inherently common in many ... is an array of characters in memory that ends with the first NULL byte. ... where Windows allows a VIRUS can inject itself in the stack stack and the ...
    (microsoft.public.security)
  • Re: Telnetd AYT overflow scanner and linux telnet 0.17
    ... Telnetd AYT overflow scanner and linux telnet 0.17 ... (NOT THE STACK) ... > efficienlty would result in a buffer that is 2 bytes smaller than it has ...
    (Vuln-Dev)
  • [UNIX] Gaim Instant Messaging Client Remote Overflows
    ... a hurried release because of a change in the Yahoo connection procedure ... The identified problems range from simple standard stack overflows, ... overflows to an integer overflow that can be abused to cause a heap ... write 1 or 2 NULL bytes past the buffer boundaries. ...
    (Securiteam)
  • Re: OT: UK okays warrantless remote hacking of PCs
    ... use of freed memory. ... it was *impossible* for code to modify code, or to overflow a stack ... That said legacy h/w issues mean that even some Unix systems on Intel ... stacks don't overflow into code. ...
    (sci.electronics.design)
Loading