Dillema con buffer overflow

Question

Sto giocando con un esempio di overflow dello stack. Questo esempio è il seguente:

void return_input (void){ 
    char array[30];  
    gets (array); 
    printf("%s\n", array); 

} 

main() { 
    return_input();  
    return 0;  
} 

Tutto questo codice si trova nel file overflow.c. Abbiamo una funzione vulnerabile denominata return_input, in particolare è un array di 30 byte char. Ho compilato e aprii la funzione vulnerabile gdb ed ho ottenuto seguente output:

(gdb) disas return_input 
0x08048464 <+0>: push %ebp 
0x08048465 <+1>: mov %esp,%ebp 
0x08048467 <+3>: sub $0x48,%esp 
0x0804846a <+6>: mov %gs:0x14,%eax 
0x08048470 <+12>: mov %eax,-0xc(%ebp) 
0x08048473 <+15>: xor %eax,%eax 
0x08048475 <+17>: lea -0x2a(%ebp),%eax 
0x08048478 <+20>: mov %eax,(%esp) 
0x0804847b <+23>: call 0x8048360 <gets@plt> 
0x08048480 <+28>: lea -0x2a(%ebp),%eax 
0x08048483 <+31>: mov %eax,(%esp) 
0x08048486 <+34>: call 0x8048380 <puts@plt> 
0x0804848b <+39>: mov -0xc(%ebp),%eax 
0x0804848e <+42>: xor %gs:0x14,%eax 
0x08048495 <+49>: je  0x804849c <return_input+56> 
0x08048497 <+51>: call 0x8048370 <__stack_chk_fail@plt> 
0x0804849c <+56>: leave 
0x0804849d <+57>: ret  
End of assembler dump. 

Come si può vedere dalla funzione di prologo abbiamo riservato hex48 (dec 72) byte sullo stack per le variabili locali. Prima stavo cercando di trovare l'indirizzo in cui il nostro array vulnerabile inizia in pila. Penso che sia -0x2a (% ebp), ho ragione? Hex2a è 42 decimali. Come ho capito significa che possiamo scrivere in modo sicuro 42 byte prima di iniziare a sovrascrivere EBP salvato nello stack. Ma quando ho eseguito questo esempio è sufficiente solo a destra 37 byte per ottenere errore di segmentazione:

rustam@rustam-laptop:~/temp/ELF_reader$ ./overflow 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Segmentation fault (core dumped) 

Come è di 37 byte sufficiente a buffer overflow? Se il nostro char array locale è -42 byte da EBP salvato

Answer 1

È difficile dire senza vedere l'intero smontaggio della funzione.

Tuttavia, la mia ipotesi è che il% gs: 0x14 memorizzato a -0xc (% ebp) potrebbe essere il tuo stack canary che causa un'uscita pulita se viene rilevato un danneggiamento dello stack. Quindi questo valore è memorizzato a -0xc (% ebp), il che significa che il buffer è in realtà solo 30 byte di grandi dimensioni, seguito da ciò che viene dopo.