Il primo overflow

Passo subito alla pratica, proprio perché nel precedente articolo ho già trattato la parte teorica. Vediamo quindi un semplice programma vulnerabile all’overflow dello stack:

#include
int main(int argc, char **argv) {
char buf[20];  //inizializzo un buffer di 20 bytes
FILE* f=NULL;
int i=0;
printf("\nTest BOF");
f=fopen("input.txt","rb"); //apro il file...

while(!feof(f)) { //...e comincio a leggerne il contenuto
buf[i]=fgetc(f); //salvo i byte nel buffer
i++;
}
fclose(f); //chiudo il file
}

Si tratta di un esempio tipico di buffer overflow, dovuto all’uso incauto di un buffer nella lettura da file. Se infatti il file contiene dati per più di 20 bytes il programma andrà in crash, visualizzando il classico avviso di Windows.

Il codice, infatti, non fa altro che leggere un carattere alla volta dal file input.txt fino alla fine per poi copiarlo nella variabile buf. Naturalmente, poiché non c’è nessun controllo sulla dimensione del file, basta superare il limite del buffer per provocare la condizione di overflow. Nell’esempio, per far crashare il programma, ho inserito di proposito una stringa di 28 bytes (AAAABBBBCCCCDDDDEEEEFFFFGGGG) dove “FFFFGGGG” sono i byte eccedenti. Ma dove finiscono questi dati? Come detto la scorsa volta i dati che causano il traboccamento del buffer vanno a sovrascrivere lo stack della memoria. In questo caso, se si usa un debugger per visionare lo stato della memoria al momento dell’overflow, si noterà che il registro EIP ha assunto il valore 0×47474747 e quello EBP il valore 0×46464646, che rispettivamente equivalgono – in esadecimale – ai caratteri GGGG e FFFF.

Primi passi verso l’exploit

Modificare il registro EIP significa, in parole povere, riuscire a modificare l’esecuzione del programma, dirigendolo in una qualsiasi zona a nostro piacere. Una volta chiarito questo punto possiamo iniziare a progettare un exploit in grado di sfruttare l’overflow individuato per prendere il controllo del programma. Si procede studiando l’esecuzione del programma fino alla condizione di overflow, passo dopo passo, grazie ad un debugger. Vediamo ora la prima parte del programma. Dovete comunque tenere conto che se disassemblate un eseguibile da voi compilato l’output potrebbe differire dal mio, ciò è dovuto dalla differenza del compilatore, od anche da una versione diversa dello stesso:

00401000 push ebp //salva EBP nello stack
00401001 mov ebp,esp
00401003 sub esp,1Ch //riserva spazio per buffer
00401006 mov dword ptr [ebp-18h],0 //variabile FILE* f
0040100D mov dword ptr [ebp-1Ch],0 //variabile int i

Questa parte iniziale di codice viene generata dal compilatore e si “preoccupa” di riservare spazio nello stack utile per allocare buf (0×1C byte) e le altre variabili. Sono riportati i valori dei registri dello stack ESP e EPB prima e dopo l’esecuzione delle istruzioni. Successivamente il programma esegue la stampa a video con printf() della stringa “Test BOF”. In linguaggio assembly i prametri di una funzione vengono passati mediante salvataggio nello stack: prima della chiamata a printf() troviamo infatti un’istruzione PUSH che memorizza nello stack l’offset della stringa di testo.

00401014 push 407030h //offset stringa  “\nTest”
00401019 call 00401114 //printf()
0040101E add esp,4
...

Analizziamo ora il ciclo while che legge fino alla fine del file i byte memorizzandoli nella variabile buf:

00401033 mov dword ptr [ebp-18h], eax
00401036 mov eax, dword ptr [ebp-18h]
00401039 mov eax, dword ptr [eax-0Ch]
0040103C and ecx,10h
0040103F test ecx,ecx //test di fine file (EOF)
00401041 jne 00401061
00401043 mov edx, dword ptr [ebp-18h]
00401046 push edx
00401047 call 004010C7 //lettura da file fgetc()
0040104C add esp,4
0040104F mov ecx, dword ptr [ebp-1Ch]
00401052 mov byte ptr [ebp+ecx-14h],al //memorizza il byte in buf
00401056 mov edx, dword ptr [ebp-1Ch]
00401059 add edx,1 //incremento variabile i (i++)
0040105C mov dword ptr [ebp-1Ch],edx
0040105F jmp 00401036

l’istruzione alla riga 12 è quella che scrive nel buffer il dato letto da file mediante fget(). L’indirizzo del buffer è dato da [EBP+ECX-14h]; il valore vinere incrementato ad ogni iterazione grazie al registro ECX. E’ tuttavia la parte finale del programma, quella che segue immediatamente all’istruzione fclose(), la più interessante: viene ripristinato il valore del registro EBP e per chiudere la procedura si esegue un’istruzione di ritorno RET. Tale istruzione ha l’effetto di estrarre una word (32 bit) dallo stack e di memorizzare in eip, modificando l’indirizzo dell’istruzione corrente e spostando così il flusso di esecuzione del programma. E’ in questo momento che emergono i problemi dell’overflow e il programma raggiunge una condizione indefinita. Il ciclo while infatti, non si accorge di scrivere nel buffer più dati di quelli previsti (28 contro 20) e di conseguenza inizia a scrivere sopra lo stack alterando i valori in esso memorizzati.

00401061 mov eax, dword ptr [ebp-18h]
00401064 push eax
00401065 call 00401071
0040106A add esp,4
0040106D mov esp,ebp
0040106F pop ebp //ripristina EBP
00401070 ret //istruzione di ritorno

Tutto ciò si traduce con un errore che scatta nel momento in cui si eseguono le istruzioni POP e RET: i valori estratti dallo stack non sono quelli corretti, ma sono diventati parte dei dati letti da input; infatti, nel momento in cui si verifica il crash, ci si accorge che i registri EBP e EIP contengono i valori 0×46464646 e 0×47474747, che corrispondono proprio ai caratteri in eccedenza nel file input.txt (rispettivamente le stringe “FFFF” e “GGGG”).
Vediamo ora com’è possibile creare un exploit capace di sfruttare l’overflow del programma di esempio. Si è visto come sia possibile controllare l’andamento del programma fornendo input in eccedenza, ma è possibile andare oltre: se nell’input invece di fornire stringhe di testo, memorizziamo istruzioni assembly a nostro piacimento, possiamo iniettare il nostro codice direttamente nello stack affidato al programma e quindi modificare l’andamento del flusso d’esecuzione, dirottando il registro EIP nel punto in cui si trova il codice iniettato. L’unica difficoltà di questa fase è il calcolo degli indirizzi e degli offset di allineamento, che dovranno combaciare perfettamente per far sì che il programma ad un certo punto esegua le nostre istruzioni; analizzando la stringa di overflow ci si accorge che il valore GGGG pilota il registro EIP. La struttura dell’exploit prevede, quindi, un input di questa forma: in testa possiamo sfruttare i primi 20 byte del buffer per memorizzare il codice che vogliamo far eseguire, aiutandoci con eventuali istruzioni NOP (istruzione assembly che corrisponde a no-operation, quindi ininfluente) per allineare il codice esattamente alla dimensione di 20 byte. Seguono due word da 32 bit che corrispondono ai valori scritti dall’overflow nei registri EBP e EIP; infine, poiché per questo exploit ho pensto di visualizzare una semplice stringa di testo, memorizzeremo nella parte finale dell’input quest’ultima, terminata da 0.

Il registro EIP servirà per dirottare il flusso del programma verso l’inizio del codice da noi iniettato. Analizzando col debugger l’esecuzione del programma, si nota che il valore di EBP prima dell’overflow è 0×0012FF80, mentre lo stack usato per memorizzare i dati inizia all’offset 0×0012FF6C, che sarà proprio il punto in cui partirà il codice iniettato. Conosciamo quindi i valori delle word di EBP e di EIP, non resta che scrivere il codice da ineittare.
Come ho accennato prima, descriverò un exploit di esempio che non frà altro che stampare a schermo una stringa di testo. E’ ovvio che ci si può spingere oltre e creare i cosiddetti shellcode, ovvero del codice assembly in grado di aprire una shell sul sistema vittima, solitamente con privilegi da amministratore. Alla fine di questo articolo accennerò alla costruzione di uno shellcode, ma un argomento del genere andrebbe approfondito non poco, e richiederebbe un articolo a parte.

Ritornando all’exploit, per stampare del testo abbiamo bisogno di conoscere l’offset in cui risiede la stringa e l’indirizzo di printf(), che come si è visto prima, è localizzata a 0×00401114. Il codice assembly da iniettare sarà il seguente, per un totale di 3+5+5=13 byte.

OPCODES	ISTRUZIONE
83 EC 20	SUB ESP, 0×20
68 x1 x2 x3 x4	PUSH offset(stringa)
E8 y1 y2 y3 y4	CALL printf()

Per raggiungere i 20 bytes richiesti dall’overflow, si aggiungono 7 istruzioni NOP alla fine del codice. Gli opcodes sono i codici esadecimali che corrispondono univocamente alle istruzioni assembly; ad esempio 83 EC identifica l’istruzione SUB ESP, che seguita dal valore 0×20, sottrae 20 byte dal registro EBP. Non rimane che calcolare i valori “x1 x2 x3 x4” e “y1 y2 y3 y4” della PUSH e della CALL. L’offset della stringa di testo si calcola partendo dall’indirizzo iniziale del nostro buffer (dove inizia il codice, 0×0012FF6C) a cui si aggiungono i 28 byte del buffer, ottenendo 0×0012FF88. Per calcolare il valore di y1 y2 y3 y4 occorre invece partire dall’indirizzo della funzione printf() 0×00401114 a cui bisogna sottrarre l’offset in cui si trova l’istruzione CALL, che è dato da 0×0012FF6C+3+5+5 = 0×0012FF79. Quindi otteniamo il valore di 0×002D119B. In definitiva:

Va specificato che gli indirizzi e gli offset delle istruzioni assembly vanno scritti al contrario, cioè leggendoli da destra verso sinistra. Per creare un file di input di fatto in questo modo basta ricorrere ad un semplice programma in c++ che unisca vari pezzi dell’exploit scrivendoli su di un unico file “input.txt”. Usando il file così generato come input per il programma mostrato ad inizio articolo, l’exploit prenderà il controllo del programma visualizzando la stringa “Exploit works”. In ogni caso, al termine della funzione printf() il programma si trova in un punto indefinito, e quindi andrà in crash comunque. Ciò si può evitare aggiungendo una chiamata ad una funzione come exit().

Windows Shellcoding

Non approfondirò questo argomento, sarebbe troppo lungo e andrebbe aldilà dello scopo di questi articoli. Scrivere degli shellcode è complesso, e non cambia solo da sistema a sistema ma addirittura a seconda delle diverse versioni dello stesso. In generale uno shellcode dovrebbe aprire una shell sul sistema vittima, ma può essere usato per richiamare qualsiasi funzione di sistema approfittando dei privilegi del programma vulnerabile al buffer overflow. La difficoltà di scrivere shellcode universali è appunto dovuto al fatto che gli indirizzi delle varie funzioni cambiano a seconda del sistema. In windows è possibile risalire a tali indirizzi con un comodo programma di nome arwin. Esso permette di estrapolare l’indirizzo di una funzione presente in una determinata libreria di sistema (DLL).

C:\>arwin kernel32.dll GetProcAddressarwin
- win32 address resolution program – by steve hanna – v.01
GetProcAddress is located at 0×77e7b332 in kernel32.dll

In questo caso siamo riusciti a capire l’indirizzo della funzione GetProcAddres, che fra l’altro è molto utile per risalire a qualsiasi altra API di sistema. Il codice da iniettare dovrà essere scritto usando gli indirizzi così ricavati, avrete quindi capito che con uno shellcode si può fare qualsiasi cosa, capacità di programmazione assembly permettendo.

Introduzione

Va anticipato che uno dei linguaggi di programmazione più predisposti al buffer overflow (d’ora in poi BOF) è senza dubbio il C/C++. Infatti a differenza di altri linguaggi permette al programmatore un controllo quasi completo sulla memoria – quasi quanto un linguaggio assembly – ma non sempre fa gli opportuni controlli, a scapito dei programmatori alle prime armi. Linguaggi come il Java, ad esempio, hanno una gestione molto sofisticata della memoria, ricorrendo ad algoritmi di de-allocazione e a sistemi come il Garbage Collector, quindi i rischi di BOF sono molto rari.
Vediamo innanzi tutto cos’è il buffer. Nella sua accezione più generale un buffer è un’area di memoria contigua, con una dimensione prefissata, utilizzata per memorizzare dati omogenei. Nel linguaggio C un buffer è rappresentato dal puntatore all’indirizzo iniziale dell’area di memoria corrispondente. Alcune funzioni della libreria standard del C (strcpy(), strcat(), gets() e la famosa scanf()) operano su buffer di caratteri senza effettuare nessun controllo sulla dimensione del buffer di destinazione (bound checking): semplicemente arrestano la loro scrittura quando non hanno più caratteri disponibili. È evidente che in questi casi è abbastanza facile incorrere in un buffer overflow. Nel caso in cui il buffer mal gestito sia una variabile automatica, sia cioè allocato sullo stack, la situazione può venire sfruttata da un attaccante per sovrascrivere l’indirizzo di ritorno di una chiamata da funzione e forzare così l’esecuzione di codice malevolo, che può essere posizionato sia nel buffer stesso che in una variabile d’ambiente.
In sintesi un buffer overflow avviene quando in un programma, al tempo di esecuzione, una certa istruzione tenta di scrivere dentro ad un buffer più informazioni di quante esso ne possa contenere.

Organizzazione della memoria

È possibile suddividere la memoria allocata ad un processo in tre zone, ognuna specializzata per una determinata funzione: un’area text, un’area dati statica ed un’area dati dinamica:

• L’area text è un’area di sola lettura, collocata nella parte più bassa dello spazio di indirizzamento di un processo, in cui vengono memorizzate le istruzioni del programma ed è condivisa da tutti i processi che eseguono lo stesso codice; un tentativo di scrittura in quest’area dà origine ad un errore.

• L’area dati statica è a sua volta suddivisa in due regioni (data e bss), una per i dati inizializzati ed un’altra per i dati inizializzati; le variabili statiche trovano posto in quest’area.

• L’area dati dinamica è divisa a sua volta in due parti: lo stack e lo heap. Quest’ultima è un’area dati dinamica che viene allocata a run time attraverso le funzioni del C come malloc() e calloc(), e cresce verso gli indirizzi alti. Viene usato per gestire variabili dinamiche e puntatori. Andrò ora a descrivere un po’ più nel dettaglio lo stack.

Lo stack e sua gestione

Lo stack è quell’area di memoria che si trova sul fondo della memoria e che viene utilizzata durante le chiamate alle funzioni per salvare lo stato corrente dell’esecuzione e per passare i parametri per argomento. Viene gestito con la politica LIFO (Last In, First Out) e mediante due istruzioni fondamentali del linguaggio assembly: PUSH e POP. La prima memorizza un dato, la seconda lo estrae seguendo il modello LIFO, l’ultimo ad entrare è il primo ad uscire. La memorizzazione dei dati nello stack segue un ordine inverso, cioè parte dal fondo e man mano che le informazioni vengono memorizzate, sale verso la cima della memoria.
La gestione dello stack è affidata a due registri a 32-bit molto importanti, chiamati EBP e ESP (base pointer e stack pointer), usati – rispettivamente – per delimitare la cima e il fondo dello stack; quando si esegue una PUSH, il registro ESP viene decrementato di un numero di byte pari alla dimensione del dato memorizzato, quando si esegue una POP il registro ESP viene invece incrementato. Le variazioni di ESP e EBP possono inoltre essere fatte anche direttamente, tramite operazioni di somma e sottrazione (ADD e SUB): ad esempio l’istruzione SUB ESP,5 riserva cinque byte nello stack. Questo tipo di struttura si rivela efficiente e utile nella gestione della gestione delle chiamate di funzioni e procedure in un programma, costituendo quello che è il meccanismo della “call chain”: una funzione può infatti richiamare un’altra funzione che a sua volta può chiamarne un’altra ancora e così via. Il sistema operativo deve poter tener traccia di tutte le chiamate innestate fra loro ed essere in grado di tornare a punti prestabiliti del programma dove richiesto. Ogni chiamata ad una funzione viene tradotta in una istruzione di tipo CALL, che ha l’effetto di congelare l’esecuzione del codice fino a quel punto, passando poi il controllo alla funzione chiamata, dopo aver salvato lo stato corrente e l’indirizzo di ritorno (return address), che servirà per riportare l’esecuzione nel punto in cui si era interrotta (il registro EIP è quello che punta sempre all’istruzione corrente). Da questo meccanismo si evince una prima considerazione importante: poiché l’indirizzo di ritorno viene salvato nello stack, una eventuale corruzione di tale area dati impedirà ad un qualsiasi programma di ritornare in uno stato consistente, con conseguente crash dell’esecuzione.
Per approfondimenti riguardo allo stack si veda il seguente link: Stack on Hacknowledge

Usi malevoli del buffer overflow

Come ho detto ad inizio articolo abbiamo a che fare con un errore particolarmente grave, che permetterebbe ad un hacker di ottenere una shell (anche root in certi casi) sulla macchina vittima.
Detto sinteticamente – comunque nei prossimi articoli vedremo il tutto più nel dettaglio – è possibile far eseguire del codice macchina semplicemente sovrascrivendo l’indirizzo di ritorno e facendolo puntare ad uno shellcode. Quest’ultimo è un “programma” in grado di sfruttare un buffer overflow, e solitamente provoca l’apertura di una shell – per questo shellcode – sulla macchina vittima. Uno shellcode viene solitamente scritto tramite codici esadecimali che identificano le varie istruzioni assembly da eseguire, successivamente questo codice viene iniettato nel buffer e fatto eseguire modificando l’indirizzo di ritorno della funzione vulnerabile. I rischi di un errore del genere in alcuni casi possono essere gravissimi, ad esempio un login che va in buffer overflow se il nome utente è troppo lungo…
Ecco un’immagine che forse vi faciliterà la comprensione di quanto detto:

In ogni caso questo è un overflow dello stack – uno dei più comuni – ma ne esistono anche altri meno conosciuti, ed anche più difficili da sfruttare: heap overflow, frame pointer exception e l’adjacent memory overflow.
L’overflow dello stack rimane il più facile da sfruttare, poiché permette di maneggiare in maniera efficace i registri EBP, ESP e EIP, fondamentali per poter eseguire del codice

Ma vediamo ora com’è possibile prevenire un BOF:

• Non Executable Stack: questa è la soluzione più radicale. Modificando il kernel del sistema si può rendere il segmento che contiene i dati dello stack non-eseguibile, in modo che se accidentalmente o volutamente un programma dovesse finire in quellaa zona di memoria verrebbe generato un cosiddetto protection fault, terminando il processo.

• Random Stack Address: Per poter pilotare il flusso di esecuzione, un exploit deve disporre di indirizzi affidabili e validi da assegnare ai registri EIP e ESP. Utilizzando uno stack con modalità di indirizzamento casuale, si potrebbe complicare la vita ad un eventuale attaccante nella realizzazione di exploit a compatibilità universale, che cioè funzionino in qualsiasi sistema in cui sia presente il programma vulnerabile.

• Bound Checking: Il problema degli overflow nasce principalmente da disattenzioni da parte del programmatore e del compilatore, che non controlla in anticipo se una variabile è soggetta a “traboccare”. Comunque anche nel C/C++ sono presenti alcuni accorgimenti da rispettare, e perfino delle funzioni safe, che appunto effettuano dei controlli sull’input in modo che non superi la grandezza del buffer a cui è destinato. Di seguito degli esempi:

strcpy(buf, ptr); //insicuro
strncpy(buf, sizebuf(buf), ptr); //sicuro

oppure con il classico scanf():

char buf[10];
scanf("%s", buf); //insicuro
scanf("%10s", buf); //sicuro

Nei prossimi due articoli tratterò appunto questo tipo di buffer overflow, applicandolo ai due sistemi operativi più famosi, ovvero Windows e Linux.