Re: Easily and Permanently prevent all stack buffer overflows

Wayne wrote:
Tauno Voipio wrote:

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.



I will do that. But while I agree buffer overflows are
the result of sloppy programming, none the less, changing
the stack push/pop from --/++ to ++/-- prevents the problem
even if sloppy programing is used. This doesn't seem to
have anything to do with paging or overflow of a memory
section, just the direction of the stack growth,
whether the stack is one or more pages.

Please, could you explain why reversing the stack growth
direction would not solve this security problem? I grant
such a drastic change to the memory system would cause
other problems, but maybe those are not unsurmountable?

I appreciate your patience with my ignorance, and your
replies. Thanks!

-Wayne


Stack and heap are in different sections, and
there is plenty of unallocated address space
in between for the memory management hardware
to catch.

For a variable allocated in stack, the buffer
overflow can always clobber unintended data:
the allocated buffer is not always allocated
last in the stack frame.

--

Tauno Voipio
tauno voipio (at) iki fi
.

Relevant Pages

  • 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)
  • 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)
  • 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: Easily and Permanently prevent all stack buffer overflows
    ... stack buffer overflows. ... So how does the direction affect total memory usage? ... an overflow of a memory section. ...
    (comp.os.linux.security)
Loading