It should be noted that the scope of the variable, buffer, or storage that caused stack buffer overflow is confined to the function where it is declared (the local variable) and its scope is within the function. Since we know that functions are executed over a stack, this flaw causes the stack buffer to overflow.

In the case of a heap buffer overflow, the impact is a little greater, as the variable that we are trying to exploit does not live on a stack but instead on a heap. All the program variables that are declared within the same method are given memory within the stack. The variables that are dynamically allocated memory during run time, however, can't be placed in the stack and are placed instead in a heap. Thus, when a program assigns memory to a variable at run time through malloc or calloc calls, it actually assigns them memory over the heap, and in a heap buffer overflow situation, this memory is caused to overflow or exploit. Let's take a look at how this works:

Now go ahead and compile the code by disabling the inbuilt protection as shown. Note -fno-stack-protector and -z execstack are the commands that aid in disabling the stack protection an making it executable.

gcc -fno-stack-protector -z execstack heapBufferOverflow.c -o heapBufferOverflow

Now that we have compiled the application, let's run it with input types that will break and execute the code as shown:

The preceding screenshot gives a starting point of heap buffer overflows. We will leave it to the reader to discover how to exploit it further and get a reverse shell out of it. The methodology employed is very similar to that we used previously.