Our PCs use what is called the STACK 'memory model' as shown here: Several areas used for specific purposes are 'stacked' one upon the other (hence the name).
The program is loaded first into the virtual memory at the bottom of the address space/model.
This is a simple, single block of memory and at lease as large as the program size on disk.
Windows systems support (and heavily use) Dynamic Load Libraries (DLL) and they get loaded
very early in the program execution. The other three areas are quite dynamic in that they grow and shrink during the life of the program.

The Free Space initially is adjacent to the top of the DLL space and runs up to the top of the virtual memory,
and the Heap and Stack don't really exist at all. When the program runs any subroutine, a block of memory
is added into the Stack at the top (which will expand downward towards the heap) and reduce the size of the Free Space from its top location. This block contains the parameters passed into the subroutine and the address of where the caller invoked the subroutine (and this is the value subject to stealing control during a buffer overrun). SubroutineA may call subroutineB and so on, pushing the stack further downward).

Somewhere in the life of the program, one or more blocks of memory are needed:

• to create control structures, eg a FAT table
  
• for I/O buffers

Such areas are dynamically allocated and the first of such is the beginning of the Heap Space.
Programs frequently use many dynamic areas and they get placed one upon the other
pushing the Heap upward. These allocated areas tend to be kept throughout the life
of the program so the Heap does not shrink unless the structure at the very top is released.

Did you notice: The Heap grows upward and Stack grows downward; What happens if they collide or worse,
one overlaps the other (call a Heap Overflow)? Nothing good for sure! The program will die with some nasty note recorded in the
Event Viewer.

I/O buffers are most frequently allocated from the heap, but sometimes, when the data is smallish
and short lived, a program may push an I/O buffer onto the stack. The practice is no longer encouraged
as any overrun jeopardizes the integrity of the entire stack.

One last note, regarding 64bit systems. Some programs need LOTS of dynamic heap space for analysis
of data. Typically these are mathematical in nature. Such programs quickly induce a Heap Overflow on
32bit systems. Thus the need for a 2^64 virtual address model.

__________________
J. O. Beard; you + tech-101.com => synergism. Secure your system now

programming languages use bounds checking to make sure a variable is within X bounds before its used?


[edit] Sorry; I saved on top of your post [/edit]

__________________
__________________
Check us out on Facebook!

Useful Guides: Networking 101 Security 101 Disable Real Time Monitoring Virus/Malware Preliminary Removal Instructions

Bounds checking is like

• var x >0 & < 100
• var emailAdd {contains '@' and at least one '.'}
• var phone {contains only digits}
• var array[y] and y <= var x above

so bounds checking refers to validating the contents of a variable, not the variable's location
(which is very difficult to find with newer programming languages like C++ and Java).

not at all
while we create a buffer of a fixed size, eg var buf = malloc(100); (buf then points to that space within the heap)
there are i/o mechanisms that know nothing about the buffer size, eg: gets(buf), which will read until the NL char is found.
Obviously, there's no assurity that the string will contain the NL before the end of the buffer.
The preferred technique today is fgets(buf, 100, stdin) which will not read more than the size of the buf (ie the 100)

In most systems, the boundaries of the Heap, Stack and Free space are not easily located EXCEPT by the memory management code of the OS
(as it should be )

__________________
J. O. Beard; you + tech-101.com => synergism. Secure your system now

Using this reference to my request to explain stack:

Keeping in mind that I am not a programmer:
Explain the security dangers and differences between a heap overflow and a stack overflow

Users are frequently presented with an update because a vulnerability has been found in a stack overflow Keeping in mind that the heap overflows up and the stack overflows down, how can I explain this in a [non-technical[/b] way?

__________________
wave:Computer Support and Help
Virus & Malware Removal
Tutorials on "How To...."
Stop Nuisance Startups

The heap overflow will be caught when the memory manager sees the overlap cause by either space expanding. This will immediately cause a crash dump. So; a heap overflow is fatal and cause by

1. the program allocating too many or too large of memory structures
2. Or the program call-depth gets very-very deep.

and is not an attack by a trojan or virus. Heap overflow is a rare event.

The stack overflow doesn't occur on a boundary violation at the lowest part of the stack, but rather on those small records created within the stack when subroutineA runs subroutineB. The overflow is not felt until subroutineB attempts to return to whoever called it (in this case A).
The pointer to A is corrupted. (btw: This is also the same problem with the buffer overlow). Two things can occur

1. a wild jump into garbage and the program crashes
2. the wild jump lands onto carefully crafted code that takes control of the system.

The stack overflow is almost always some form of an attack and far more dangerous.


Don't try. The heap overflow is a condition in the original program and the user needs another fix or release caused by poor programming or just too much data being processed.

The stack overflow is explained above.

That's as simple as I can describe it and if it's still to technical -- I'm sorry.

__________________
J. O. Beard; you + tech-101.com => synergism. Secure your system now