Re: How to develop a random number generation device

On Sep 12, 2:39 pm, David Brown
<david.br...@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
MooseFET wrote:
On Sep 11, 4:58 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
[... buffer overflow ...]
It sounds to me like C compilers/linkers tend to allocate memory to
code, buffers, and stack sort of anywhere they like.

It's up to the linker to build the segments, and the run-time
link-loader picks the addresses - the compiler is not involved in the
process.

I included the linker in the "compiler/linker" in many cases they are
the same program. In many environments the segments end up in memory
in the same order as they were in the file.




No the problem isn't really with code mixed with data. It is data
mixed with data. The return addresses etc are on the stack along with
the local arrays. This means that a routine can overwrite the return
address with data by walking off the end of an array. Once that
happens the return instruction jumps you to the bad code.

That's a common sort of buffer overflow (it's not the only one, but it's
a good example). But as long as you can't execute code in the stack or
data segments, it's difficult to exploit such overflows for anything
more than crashing the program (since you can only jump to existing
code). When the system lets you execute from the stack or the data
sections, the attacker has more flexibility since they can insert their
own machine code into the program's data, then execute it.

Thus the main protection against malicious buffer overflow attacks is to
ensure that the stack and data segments are marked non-executable
(something Linux has had for ages, and windows has caught up with - if
you enable it). Of course, that means that self-modifying code can't
work, which is a problem for just-in-time compilers and certain other
techniques such as trampolines.

The other protective mechanism is to randomise the addresses of the
segments (supported in Linux, and possibly now in Vista?). This makes
it almost impossible to pick suitable addresses when overwriting the
return address on a buffer overflow, so that at best you can cause a
crash but not specific malicious behaviour.

Why can't at least the compilers be fixed so
that they put all the stacks first, then the code, then all the
buffers?

Traditionally on most architectures, you get the code first, then the
statically allocated data (initialised data followed by uninitialised
data), then the heap. The stack starts at the top of memory and grows
downwards - the heap and stack meet in the middle when you run out of
memory. On modern OS's with virtual memory, the code, data, heap and
stack are often separate.

With an x86's MMU, you can make segments for code and stack and the
like that have limits on their sizes. The problems can be partly
overcome by this.

On most programs, the stack is just above the data segment in physical
memory and the malloc() obtained memory is beyond that.


.

Relevant Pages

  • Re: where do the automatic variables go ?
    ... and bss segments etc...but there is notthing like stack and heap ... automatic objects are placed in some kind of "stack ... like" memory (which under most implementations happens to be an actual ... objects on a stack is also perfectly conforming. ...
    (comp.lang.c)
  • RE: considerations about exploits tricks
    ... you can attempt to fix the stack for a start. ... This still does not stop heap attacks - ... the heap area and other data areas - not just the stack. ... any buffer overflow exploit that overflows ...
    (Security-Basics)
  • Buffer overflow prevention
    ... I have an idea on buffer overflow prevention. ... procedure return address and for local variables. ... have two stacks -- one for real stack and one for variables -- it will solve ... Of course, this two segments can be made non-executable, just in case. ...
    (Bugtraq)
  • Re: Buffer overflow prevention
    ... > I have an idea on buffer overflow prevention. ... > the fact that we're using the stack, referenced by SS:ESP pair, both ... > procedure return address and for local variables. ... if we use first segment for passing variables ...
    (Bugtraq)
  • Re: How to develop a random number generation device
    ... code, buffers, and stack sort of anywhere they like. ... That's a common sort of buffer overflow ... But as long as you can't execute code in the stack or data segments, it's difficult to exploit such overflows for anything more than crashing the program. ... The stack starts at the top of memory and grows downwards - the heap and stack meet in the middle when you run out of memory. ...
    (sci.electronics.design)