Buffer Overflow

1. Corso di Sistemi Operativi Buffer Overflow Gianluca Mazzei Andrea Paolessi Stefano Volpini Prof. Alfio Andronico Prof.ssa Monica Bianchini

2. Buffer Overflow (BOF) • Introduzione: • capire l’importanza del problema; alcune definizioni ed organizzazione dei processi in memoria per una più facile comprensione; • Esempio: • passo passo attraverso un tipico caso di Buffer Overflow su architettura tipo Intel x86 e sistema operativo Linux; • Soluzioni: • comprensione delle metodologie di protezione; pro e contro delle tecniche più usate per evitare i Bof; GAS

3. Introduzione I buffer overflow vengono sfruttati per attaccare e prendere il controllo del sistema da parte di un utente non autorizzato (attacker). Consiste sostanzialmente nello scrivere nel buffer (tipicamente un array) una quantità di dati maggiore dello spazio ad esso allocato. In determinati casi il Sistema Operativo non rileva questa situazione, quindi i dati in eccesso andranno a sovrascrivere una parte di memoria non assegnata al buffer. GAS

4. Organizzazione dei processi in memoria. I processi sono divisi in tre regioni: Generalmente vengono sfruttati i BOF nello stack facendo una chiamata ad una funzione che prende in ingresso dei dati dall’utente e li copia in un buffer (allocato sullo stack) senza controllare che abbia capacità sufficiente. GAS

5. Definizioni di base • Buffer : • è un blocco contiguo di memoria che contiene più istanze dello stesso tipo di dato. In C un buffer viene normalmente associato ad un array. • Overflow : • l’ overflow (traboccamento) di un buffer consiste nel riempire oltre il limite tale buffer. • Stack : • zona contigua di memoria gestita con tecnica LIFO e 2 operazioni principali: push e pop per aggiungere e rimuovere un elemento dalla cima dello stack. GAS

6. Esempio di chiamata a funzione Riempimento dello stack GAS

7. Esempio di chiamata a funzione Riempimento dello stack SP, FP GAS

8. Esempio di chiamata a funzione SP FP GAS

9. Esempio di chiamata a funzione SP FP GAS

10. Esempio di chiamata a funzione All’uscita della funzione chiamata vengono recuperati il Frame Pointer (FP) e l’Instruction Pointer (IP) dallo stack e ripristinati nei rispettivi registri in modo da far proseguire l’esecuzione del programma principale con l’istruzione successiva alla chiamata di f. Vediamo adesso un caso di overflow del buffer: GAS

11. Esempio di BOF Riempimento dello stack SP, FP GAS

12. Esempio di BOF SP FP GAS

13. Esempio di BOF SP FP e -> 0x65 GAS

14. Esempio di BOF Siccome la funzione non prevede alcun controllo della dimensione del parametro passato, la stringa (“arrivederci”) è stata accettata nonostante le dimensioni (11) fossero maggiori della capacità del buffer (4). Questo provoca l’overflow del buffer e la conseguente sovrascrittura del FP, IP ed *s. GAS

15. Esempio di BOF • All’uscita dalla funzione, quindi, l’IP non conterrà più il corretto valore di ritorno, ma 0x65 che sarà l’indirizzo della successiva istruzione che dovrebbe essere processata: • 0x65 indirizzo non valido => segmentation violation • 0x65 indirizzo valido => malfunzionamento del programma GAS

16. Sfruttare i BOF Come facciamo ad eseguire codice arbitrario sfruttando questi errori di programmazione? Un buffer overflow ci permette di cambiare l'indirizzo di ritorno di una funzione! In questo modo possiamo cambiare il flusso d'esecuzione del programma… GAS

17. Sfruttare i BOF Ora che sappiamo che possiamo modificare l'indirizzo di ritorno e il flusso d'esecuzione, quale programma dobbiamo eseguire? Nella maggior parte dei casi vogliamo semplicemente che il programma ci dia una shell. Dalla shell poi possiamo eseguire tutti i comandi che vogliamo. GAS

18. Sfruttare i BOF Ma che facciamo se nel programma non c'è il codice che vogliamo exploitare? Come possiamo inserire istruzioni arbitrarie nel suo spazio d'indirizzo? La risposta è mettere codice arbitrario nel buffer che stiamo exploitando, e sovrascrivere l'indirizzo di ritorno in modo tale da ritornare nel buffer. GAS

19. Bof, il caso classico – bof1.c Esempio di codice vulnerabile: il parametro passato dall’utente viene copiato nel buffer senza controlli sulle dimensioni GAS

20. Bof, il caso classico Parametro di dimensioni 1  OK Parametro di dimensioni 100  Segmentation fault GAS

21. Bof – Analisi dell’assembler • Vengono riservati nello stack : • 88 bytes al buffer • (8 di align) • 4 bytes all’ FP • L’ IP si trova ad un offset di 92 bytes dall’inizio del buffer e viene sovrascritto. … 39 f: 40 pushl %ebp 41 movl %esp, %ebp 42 subl $88, %esp 43 subl $8, %esp 44 leal -88(%ebp), %eax 45 pushl %eax 46 pushl $.LC0 47 call printf 48 addl $16, %esp 49 subl $8, %esp 50 pushl 8(%ebp) 51 leal -88(%ebp), %eax 52 pushl %eax 53 call strcpy 54 addl $16, %esp 55 movl %ebp, %esp 56 popl %ebp 57 ret GAS

22. Allineamento dello stack • Lo stack, di default, viene allineato dal compilatore a 4 word • FP e IP occupano 1 word ciascuno • Il compilatore aggiunge automaticamente 2 ulteriori word di allineamento per arrivare a 4. GAS

23. Come attaccare Esistono diversi metodi di attacco: il più generale procede secondo il seguente schema: • Individuare l’indirizzo di ritorno (IP) nello stack Nel nostro esempio abbiamo verificato che si trova a 92 b dall’inizio del buffer • Sovrascrivere l’ IP con l’indirizzo del buffer • Porre all’inizio del buffer il codice di attacco GAS

24. L’exploit - exp1.c Crea la stringa da passare a bof1 con codice di attacco (shellcode) e IP fornito dall’utente al corretto offset GAS

25. L’exploit - exp1.c Con un indirizzo non valido si ottiene un segmentation fault ma anche il corretto indirizzo del buffer GAS

26. Capire la shellcode Avendo dirottato l’esecuzione del programma sulla shellcode dovremo fare in modo che sia già scritta in forma eseguibile. In linea di principio per realizzare l’azione di attacco possiamo: • scrivere in C le funzioni necessarie • disassemblarle e ricomporle in un codice adattato alle nostre esigenze • usare un debugger per codificare, in forma esadecimale di op-codes e operandi, il codice costruito GAS

27. La shellcode in C La funzione execve esegue il primo parametro passatogli (/bin/sh) e lancia quindi una shell GAS

28. La shellcode disassemblata [stefano@localhost Desktop]$ gcc -o sc -ggdb -static sc.c [stefano@localhost Desktop]$ gdb sc (gdb) disassemble main Dump of assembler code for function main: 0x8000130 <main>: pushl %ebp 0x8000131 <main+1>: movl %esp,%ebp 0x8000133 <main+3>: subl $0x8,%esp 0x8000136 <main+6>: movl $0x80027b8,0xfffffff8(%ebp) 0x800013d <main+13>: movl $0x0,0xfffffffc(%ebp) 0x8000144 <main+20>: pushl $0x0 0x8000146 <main+22>: leal 0xfffffff8(%ebp),%eax 0x8000149 <main+25>: pushl %eax 0x800014a <main+26>: movl 0xfffffff8(%ebp),%eax 0x800014d <main+29>: pushl %eax 0x800014e <main+30>: call 0x80002bc <execve> 0x8000153 <main+35>: addl $0xc,%esp 0x8000156 <main+38>: movl %ebp,%esp 0x8000158 <main+40>: popl %ebp 0x8000159 <main+41>: ret GAS

29. Shellcode - composizione “pseudo-assembler” Evitando di addentrarsi nei dettagli (v. relazione allegata) si procede in maniera analoga per altre funzioni utili (execve, exit, etc.) e riadattando i disassemblati alle nostre esigenze; A questo punto siamo in grado con il codice prodotto di lanciare il comando /bin/sh a patto di conoscere l’indirizzo in cui tale stringa è memorizzata. Si pone però il problema di non conoscere questa posizione poiché viene allocata in fase di esecuzione e varierà da macchina a macchina, da architettura ad architettura, etc., quindi non sarà mai possibile fissarla definitivamente. GAS

30. Trovare l’indirizzo di /bin/sh La soluzione migliore è quella di utilizzare riferimenti relativi, in modo che il programma sia in grado di calcolarsi da solo gli offset e quindi funzioni indipendentemente da dove verrà allocato. Per questo motivo useremo delle istruzioni di tipo JMP e CALL che consentono di saltare di un certo offset a partire dall'IP corrente. L’istruzione CALL salva nello stack l'indirizzo assoluto successivo a quello che la contiene.

31. Verso l’assembler definitivo • Tenendo presente il numero di bytes occupato da ogni istruzione, si risolvono tutti gli indirizzi relativi a JMP e CALL • A partire dall’indirizzo della stringa recuperato dalla POP si risolvono gli offset degli indirizzi necessari a lanciare il comando tramite un indirizzamento indicizzato tramite un apposito registro (ESI, Extended Stack Index). GAS

32. Codifica esadecimale Adesso siamo giunti al punto di utilizzare il debugger gdb per ottenere il codice in esadecimale. Prendiamo ad esempio la prima istruzione ottenuta: 0x8000133 <main+3>: jmp 0x800015f Per tradurla basterà eseguire in gdb il comando: (gdb) x/bx main+3 ottenedo così: 0x8000133 <main+3>: 0xeb(gdb)0x8000134 <main+4>: 0x2a(gdb) GAS

33. Codifica esadecimale La stringa risultante è quindi: “ \xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00 \x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80 \xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff \xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3" GAS

34. Correggere la Shellcode Il nostro codice dovrà andare a finire in un buffer di caratteri terminato da NULL. Questo significa che la nostra shellcode non dovrà contenere alcun carattere 0x0 che verrebbe altrimenti interpretato come terminazione della stringa bloccandone l’esecuzione. Individuiamo allora le istruzioni che introducono dei NULL e trasformiamole in istruzioni equivalenti che non presentino questo problema. GAS

35. La Shellcode definitiva La shellcode relativa risulta: che corrisponde esattamente a quella con cui abbiamo attaccato il programma vulnerabile di esempio. GAS

36. Ottimizzare la Shellcode Bof1.c ci dice dove inizia il buffer, ma in generale non sarà così facile… Come facciamo per deviare l’esecuzione sulla JMP ? • Scrivendo un indirizzo a caso nell’ IP e tentando di azzeccare l’inizio del buffer (!?) • Riempiendo di NOP la parte iniziale del buffer • Basta imbattersi in una NOP qualsiasi per arrivare comunque alla JMP! (con 100 NOP la probabilità aumenta 100 volte) • A volte non praticabile: se il buffer è troppo piccolo è necessario indirizzarsi verso un’altra zona di memoria GAS

37. Soluzioni • I bof sono un problema rilevante per le molte possibilità che offrono di attaccare il sistema e renderlo accessibile, compromettendone seriamente la sicurezza. • Si rendono quindi necessarie delle contromisure che permettano di evitare che si verifichi questo problema in qualsiasi situazione. GAS

38. Evitare i bof: programmazione ottimale • La soluzione più immediata e sicura consiste nell'inserire controlli sulle dimensioni dei parametri inseriti dall'utente implementando, nel codice stesso del programma, le istruzioni di controllo necessarie. • In questo modo si farà in modo da impedire che la quantità di dati da copiare non ecceda le dimensioni del buffer scongiurando il pericolo di un possibile overflow. GAS

39. Programmazione ottimale: codice vulnerabile (bof1.c) Obbiettivo: rifiutare una stringa immessa maggiore di 80 caratteri GAS

40. Programmazione ottimale: codice corretto (bof2.c) La funzione strlen() restituisce la dimensione di una stringa passatagli. GAS

41. Outputs di bof2.c Eseguendo bof2.c con un parametro di dimensioni eccessive il programma uscirà senza far niente se non visualizzare il previsto messaggio di errore. GAS

42. Evitare i Bof: funzioni "sicure" • Il problema dell'overflow nel caso precedente è causato dal fatto che la funzione strcpy(b, s) non controlla che le dimensioni del buffer b allocato sullo stack siano sufficienti a contenere l'intera stringa s ed esegue ugualmente la copia della stringa continuando a scrivere sullo stack fuori dallo spazio allocato. • Strncpy(), che oltre ad eseguire la stessa funzione di strcpy() impone un limite massimo alle dimensioni della stringa definito da un terzo parametro; • Se quindi la stringa eccede tale limite essa verrà troncata e poi copiata nel buffer. GAS

43. Funzioni "sicure": codice corretto (bof3.c) Utilizzando strncpy(b, s, bufdim), ove bufdim è ladimensione del buffer, si produrrà l’effetto di troncare qualsiasi stringa s copiata alla dimensione specificata. GAS

44. Outputs di bof3.c Stavolta non si verifica un segmentation fault poichè è stata copiata la stringa troncata all'ottantesimo carattere, quindi non è stato scritto nulla al di fuori del buffer. GAS

45. Problemi • L'utilizzo di funzioni come strncpy() induce degli svantaggi: • API non intuitiva, che induce non pochi errori in fase di sviluppo, tipo sul passaggio dei parametri che possono variare in quantità e posizione rispetto alla funzione primitiva; • Uso incoerente del parametro che indica lunghezza/dimensione (per strncpy() si tratta di sizeof(dest) per strncat() di sizeof(dest)-1); GAS

46. Problemi • Difficolta' nell'accorgersi di un troncamento avvenuto (per strncpy() si deve controllare con strlen(dest), per strncat() bisogna tenere copia del vecchio valore di dest); • Strncpy() non termina in ogni caso con NULL la stringa di destinazione, quindi bisogna impostare a NULL l'ultimo byte manualmente nel caso in cui strlen(sorgente) >= sizeof(destinazione); • Strncpy() ha performance pessime (dipendentemente dalla CPU, strncpy() e` dalle 3 alle 5 volte piu' lento di strcpy(); questo perche' lo spazio in eccesso viene posto esplicitamente a '\0'). GAS

47. Altre funzioni "sicure": strlcpy() e strlcat() Strlcpy() e strlcat() offrono un' interfaccia più intuitiva: Entrambe occupano per intero il buffer di destinazione (non solo per la lunghezza della stringa da copiare come in strncpy()), garantiscono la terminazione della stringa con NULL e restituiscono la lunghezza totale della stringa che è loro intenzione creare, ovvero la dimensione della stringa di destinazione se questa non viene troncata a causa di un buffer non abbastanza grande da contenerla. Svantaggio:strlcpy() e strlcat() non vengono però installate di default in molti sistemi Unix-like. E’ comunque possibile includerle nello stesso programma sorgente data la loro dimensione ridotta. GAS

48. Svantaggi della programmazione ottimale • La modifica del codice non è però sempre di facile applicazione: • Gli attuali programmi sono costituiti da una grossa mole di codice che causa un oneroso lavoro di analisi; • Il numero di applicazioni correntemente usate è in continua crescita e pertanto il numero di programmi che andrebbero rianalizzati in profondità a partire da zero è sempre maggiore. GAS

49. Evitare i Bof: Allocazione dinamica del buffer Strncpy() e simili sono un esempio di buffer allocato staticamente, ovvero una volta allocato la sua dimensione resta fissa. Con l’allocazione dinamica viene ridimensionato a seconda delle esigenze. Se viene inserita una stringa di grosse dimensioni il buffer si espande in maniera tale da poterla memorizzare per intero, quindi non si ha overflow. GAS

50. Problemi nell’allocazione dinamica del buffer • L'allocazione dinamica può provocare un esaurimento di memoria anche in punti nel programma non soggetti a bof, quindi qualsiasi allocazione di memoria può fallire. • Anche se non viene esaurita la memoria, la minore efficienza nell'allocazione stessa causa un numero maggiore di accessi alla memoria virtuale rispetto all'allocazione statica per cui è più facile causare il "trashing“. GAS