dangers of heap overflows?

Question

I have a question about heap overflows.

I understand that if a stack variable overruns it's buffer, it could overwrite the EIP and ESP values and, for example, make the program jump to a place where the coder did not expect it to jump.

This seems, as I understand, to behave like this because of the backward little endian storing (where f.e. the characters in an array are stored "backwards", from last to first).

If you on the other hand put that array into the heap, which grows contra the stack, and you would overflow it, would it just write random garbage into empty memory space then?
(unless you where on a solaris which as far as I know has a big endian system,side note)
Would this basicly be a danger since it would just write into "empty space"?
So no aimed jumping to adresses and areas the code was not designed for?
Am I getting this wrong?

To specify my question:
I am writing a program where the user is meant to pass a string argument and a flag when executing it via command line, and I want to know if the user could perform a hack with this string argument when it is put on the heap with the malloc function.

Answer 1

If you on the other hand put that array into the heap, which grows contra the stack, and you would overflow it, would it just write random garbage into empty memory space then?

You are making a couple of assumptions:

1. You are assuming that the heap is at the end of the main memory segment. That ain't necessarily so.

2. You are assuming that the object in the heap is at the end of the heap. That ain't necessarily so. (In fact, it typically isn't so ...)

Here's an example that is likely to cause problems no matter how the heap is implemented:

  char *a = malloc(100);
  char *b = malloc(100);
  char *c = malloc(100);
  for (int i = 0; i < 200; i++) {
      b[i] = 'Z';
  }

Writing beyond the end of b is likely to trample either a or c ... or some other object in the heap, or the free list.

Depending on what objects you trample, you may overwrite function pointers, or you may do other damage that results in segmentation faults, unpredictable behaviour and so on. These things could be used for code injection, to cause the code to malfunction in other ways that are harmful from a security standpoint ... or just to implement a denial of service attack by crashing the target application / service.

Answer 2

There are various ways heap overflow could lead to code execution:

• Most obvious - you overflow into another object that contains function pointers and get to overwrite one of them.
• Slightly less obvious - the object you overflow into doesn't itself contain function pointers, but it contains pointers that will be used for writing, and you get to overwrite one of them to point to a function pointer so that a subsequent write overwrites a function pointer.
• Exploiting heap bookkeeping structures - by overwriting the data that the heap allocator itself uses to track size and status of allocated/free blocks, you trick it into overwriting something valuable elsewhere in memory.
• Etc.

For some advanced techniques, see:

http://packetstormsecurity.com/files/view/40638/MallocMaleficarum.txt