Un modello integrato control-flow e data-flow per il rilevamento automatico di intrusioni

Transcript

1 Università degli Studi di Udine Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea Specialistica in Informatica Tesi di Laurea Un modello integrato control-flow e data-flow per il rilevamento automatico di intrusioni Candidato: Matteo Cicuttin Relatore: Prof. Marino Miculan Anno Accademico 2010/2011 Università degli Studi di Udine Via delle Scienze, Udine Italia

2

3 Alla mia famiglia, che mi ha sempre supportato.

4

5 Ringraziamenti In questo percorso mi sono trovato ad affrontare molte situazioni impegnative, quindi desidero innanzitutto ringraziare chi mi era vicino in quei momenti per avermi sopportato, Ilaria in particolare. Spesso il suo aiuto è stato determinante e spesso non sono stato capace di ricambiarlo. Il successivo ringraziamento va al mio relatore, Prof. Miculan, per l opportunità che mi ha dato e per il clima in cui questo lavoro si è svolto. Sono in debito con lui. Tra quelli che devo ringraziare ci sono anche gli amici, interni ed esterni all università, compresi quelli che ultimamente hanno perso un po la testa. Con loro ho condiviso momenti di divertimento e importanti scambi di idee. Naturalmente il ringraziamento più grande va alla mia famiglia per avermi supportato in questo percorso, nonostante i momenti difficili. Anche se non leggeranno mai questi ringraziamenti, desidero dire grazie a chiunque sia coinvolto nello sviluppo dei software che ho usato per mettere insieme questa tesi. Per scriverla ho usato Vim ma mi sono serviti anche un sacco di altri programmi, tra cui: L A TEX, GraphViz, GHC, GCC, GDB, NASM, Subversion, le shell Bourne e Korn, DTrace e anche qualcosina closed source come OmniGraffle. Questi software mi hanno permesso tra l altro di creare dei tool che hanno automatizzato molte parti del mio lavoro, semplificandolo enormemente. Il loro denominatore comune però è il sistema operativo che li fa girare, ovvero Unix. Ho usato in particolare Mac OS X per elaborare il testo e la grafica e Solaris (OpenIndiana) per tutta la parte legata a DTrace. FreeBSD invece sul mio server garantiva tutta una serie di servizi che mi sono stati assai utili, storage e backup in primis. Senza Unix e tutto quello che ci sta sopra tutto questo sarebbe stato infinitamente più difficile e frustrante. Desidero infine rivolgere un ringraziamento particolare a Chad Mynhier, che mi ha fornito materiale e consigli preziosissimi relativamente a DTrace. Durante questa laurea specialistica poche cose sono andate come pensavo e sono particolarmente felice di essere finalmente giunto al traguardo, anche se purtroppo la felicità di questi giorni è offuscata dalla cattiva salute del mio Micio. Con la laurea triennale avevo visto la punta di un iceberg, con la laurea specialistica ho

6 iv Ringraziamenti scoperto nuovi mondi. Spero che il futuro mi riservi una strada che mi consenta di non smettere di studiare.

7 Indice 1 Introduzione Anomaly detection e system call Obiettivo del lavoro Struttura della tesi Modelli per l anomaly detection Modelli control flow Automi a stati finiti VtPath Execution graphs Abstract stack, un modello costruito staticamente Modelli data flow Un modello data flow Discussione dei modelli studiati Un modello che integra control flow e data flow Debolezze dei modelli esistenti Primo scenario: vulnerabilità nel codice Secondo scenario: errore di configurazione di un server Terzo scenario: debolezza delle relazioni binarie Proposta Costruzione del modello Algoritmo di apprendimento delle relazioni unarie Algoritmo di apprendimento delle relazioni binarie Descrizione dell algoritmo L algoritmo completo per la costruzione del modello Relazione con l algoritmo originale rispetto ai falsi positivi Una possibile variante

8 vi Indice 3.5 L algoritmo per la verifica delle tracce rispetto al modello Gestione delle anomalie L implementazione Struttura generale del sistema Introduzione a DTrace Interfacciamento a DTrace tramite libdtrace(3lib) Note riguardo a DTrace Implementazione del sistema Lo script di data collection Implementazione di NewArgs() Costo computazionale del modello Costo del learning Costo della verifica Alcuni dati sperimentali Conclusioni e sviluppi futuri Riepilogo del lavoro svolto Il modello L implementazione Sviluppi futuri L uso dello stack nell apprendimento delle relazioni binarie Una dimensione statistica per il modello Costruzione statica del modello Applicazione del modello a sistemi virtualizzati Bibliografia 69

9 Elenco delle figure 1.1 Codice semanticamente equivalente Buffer overflow Architettura generale di un sistema black-box FSA d esempio Esempio riguardante la parte induttiva della definizione dell EG Rappresentazione grafica del significato di successore Time to check to time of use Banale programma vulnerabile ad un non-control data attack Informazioni apprese a runtime dall analisi data flow Programma vulnerabile d esempio FSA per il primo esempio Execution graph per il primo esempio Passi dell attacco al programma Programma per il secondo esempio FSA per il secondo esempio Execution graph per il secondo esempio Codice d esempio per il terzo scenario Nuovo modello per l esempio del primo scenario Nuovo modello per l esempio del terzo scenario Esecuzione dell algoritmo su una traccia Esecuzione dell algoritmo su una traccia Struttura generale del sistema Script di DTrace per monitorare lo stack Tempi di esecuzione di ls senza e con tracing Script di DTrace per monitorare lo stack Strutture dati usate da un consumer DTrace

10 viii Elenco delle figure 4.6 Snippet di walk() Struttura dati di supporto all implementazione di NewArgs() Automa senza e con peso sugli archi

11 1 Introduzione Dai tempi della dot-com bubble stiamo assistendo ad una crescita enorme della diffusione di dispositivi informatici di ogni tipo e, a differenza di dieci anni fa, è abbastanza difficile pensare di poter vivere senza interagire ogni giorno con un computer potenzialmente connesso alla rete. Router casalinghi e telefonini montano CPU sufficientemente potenti da poter far girare un kernel Unix, per non parlare di televisori e media-center. Se pensiamo a quanti di questi dispositivi ognuno di noi ha in casa e, soprattutto, alla quantità di dati personali che essi manipolano, la loro protezione da attacchi informatici diventa un obiettivo primario. Le minacce per un computer, comprendendo negli oggetti indicati con questa parola anche i dispositivi appena citati, sono dei tipi più svariati ed impensabili e le tecniche di difesa sono letteralmente centinaia, ognuna volta a proteggere da determinati tipi di attacchi. Volendo prescindere dalla tipologia d attacco possiamo distinguere due metodologie fondamentali nel rilevamento, la misuse detection, altrimenti detta signaturebased detection e la anomaly detection. Gli antivirus in buona approssimazione fanno un lavoro di misuse detection: essi infatti, dato ad esempio un file eseguibile, sono in grado di cercare al suo interno delle sequenze di byte corrispondenti a payload malevoli già noti. Il confronto è puramente sintattico e quindi una versione B del payload sintatticamente diversa ma semanticamente equivalente potrebbe non venire rilevata. Prendiamo i due frammenti di assembler x86 di Figura 1.1: jmp 0x01ab23cd push 0x01ab23cd ret (a) (b) Figura 1.1: Codice semanticamente equivalente. l effetto netto del codice è esattamente lo stesso, quindi semanticamente sono identici

12 2 1. Introduzione ma nel caso (a) la signature è E9 C2 23 AB 01 mentre nel caso (b) è 68 CD 23 AB 01 C3, quindi sintatticamente sono diversi. Se un programma antivirus conosce la prima signature ma non la seconda il payload passa inosservato e il virus può fare il suo lavoro. Naturalmente gli antivirus sono un po più furbi di così, ma anche chi scrive i virus è molto furbo e si serve di payload polimorfici, crittografati e quant altro, molto difficili da rilevare (si veda ad esempio [23]). Al fine di contrastare questo tipo di payload sono stati proposte diverse soluzioni basate sulla semantica [19, 5, 20] ma, purché molto potenti, anche queste sono aggirabili. Un idea fondamentale da tenere in considerazione però è che per poter attaccare un sistema è necessario interagire con esso, ed è qui che entra in gioco l anomaly detection. Per quanto l affermazione precedente possa sembrare banale è abbastanza naturale chiedersi se le interazioni che avvengono sono lecite o meno. Quello che in genere succede è infatti che tramite interazioni non lecite un sistema viene spinto a comportarsi in un modo non previsto originariamente dai suoi progettisti creando quindi un anomalia nel suo comportamento, una deviazione rispetto a quello che dovrebbe essere il comportamento corretto. Rilevare un attacco dunque corrisponde all accorgersi della presenza di questa anomalia. Sorgono alcune domande: Quale è il comportamento corretto di un sistema? Come può essere rappresentato? Come si può rilevare un anomalia? L anomaly detection prevede l esistenza di un modello che descriva quali sono i comportamenti corretti del sistema. A runtime il sistema viene monitorato costantemente e viene verificata la conformità delle sue azioni rispetto al modello. Naturalmente più il modello è dettagliato più il rilevamento di anomalie sarà accurato e più il suo costo computazionale sarà elevato: la costruzione del modello è un punto critico. In letteratura è possibile trovare moltissimi modelli per l anomaly detection costruiti nei modi più svariati e con gli obiettivi più svariati. La distinzione fondamentale che però va fatta tra tutti i vari modelli esistenti è dovuta alla modalità con cui sono costruiti, ovvero se con tecniche black-box o con tecniche white-box. Le prime prevedono soltanto l osservazione di un processo a runtime, le seconde richiedono che sia fatta un analisi sul codice sorgente o comunque sul codice binario del programma. La ricaduta fondamentale ovviamente è sull applicabilità. Il codice sorgente non sempre è disponibile e le analisi sul binario sono tutt altro che semplici. Nel caso

13 1.1. Anomaly detection e system call 3 dell architettura x86, attualmente la più diffusa in ambiente desktop e server, il problema di disassemblare correttamente un binario è addirittura indecidibile [25, 14]. Certamente disassemblatori come IDAPro fanno un egregio lavoro ma il loro output, per quanto vicino al codice vero, è inerentemente non corretto. Una conseguenza di questo fatto è che la ricostruzione del control flow di un programma dato il suo binario non è possibile, se non in modo approssimato. Un interessante lavoro in questa direzione basato sull interpretazione astratta è [11]. Le tecniche blackbox di contro, pur essendo universalmente applicabili, possono osservare soltanto le interazioni di un processo con l ambiente (ad esempio col sistema operativo o con la rete). Potrebbe succedere però che, pur osservando per tempi molto lunghi un processo, non si riesca ad osservare tutte le interazioni ottenendo anche in questo caso un quadro incompleto. Le tecniche white-box tipicamente sono di tipo statico, mentre le black-box di tipo dinamico. Le prime quindi necessitano della capacità di riconoscere ed elaborare sintassi e semantica del programma che si vuole analizzare (quindi devono avere la capacità di leggere ed interpretare il codice sorgente o il codice eseguibile) e questo richiede il supporto di tool abbastanza complessi, come ad esempio il compilatore, il che introduce un ulteriore livello di complessità. Le tecniche black-box al contrario richiedono una fase di apprendimento in cui tramite l osservazione viene costruito il modello. La bontà di quest ultimo è direttamente legata al training svolto. Come nel caso del testing del software, anche il training del modello deve essere fatto cercando di massimizzare la copertura dei casi. Nel caso del testing però se la copertura non è adeguata non si scoprono possibili bug, nel caso dei modelli black-box invece si ha una quantità inaccettabile di falsi positivi. 1.1 Anomaly detection e system call Una tecnica d attacco notevolmente diffusa è quella di fornire ad un programma un input confezionato ad hoc per far si che esso esca dal suo comportamento previsto ed esegua delle azioni utili al malintenzionato. Nel 1996 Aleph One in [17] mostrava come, sfruttando una copia di stringhe fatta senza controllare i bound, fosse possibile iniettare codice arbitrario in un programma e portarlo a lanciare una shell. Come si può immaginare, se il programma gira con privilegi di superutente, in questo modo è possibile ottenere il controllo completo sul sistema. L idea di questo tipo di attacco è molto semplice e in Figura 1.2 è riportato un programma vulnerabile. Nel frammento di codice la stringa some other string viene copiata in buf, che è un vettore allocato sullo stack. Non essendoci alcun controllo sul numero di caratteri

14 4 1. Introduzione 1 void g(void) 2 { 3 char buf[128]; 4 strcpy(buf, some_other_string); 5 } 6 7 void f(void) 8 { 9 g(); 10 } Figura 1.2: Buffer overflow. copiati è possibile scrivere oltre la fine del vettore, fino ad arrivare al record di attivazione della procedura g. Nel record di attivazione è memorizzato il punto del programma al quale restituire il controllo una volta che g è terminata: se lo sovrascriviamo con l indirizzo di buf e in buf inseriamo del codice eseguibile, esso verrà eseguito senza problemi. Una buona prassi da seguire durante la stesura del codice consiste quindi nell evitare di allocare vettori sullo stack e preferire l utilizzo di malloc(). Naturalmente questo non evita totalmente questo tipo di problemi, tant è che dal buffer overflow (il tipo di attacco appena visto) si è passati ad altri attacchi più sofisticati che vanno sotto i nomi di jump to register, heap overflow, return into libc solo per citarne alcuni. Questo tipo di approccio ha avuto (ed ha) un successo tale che esistono dei framework (Metasploit) che permettono la costruzione semiautomatica dell attacco. Gli sforzi fatti per contrastare questo tipo di attacchi sono stati svariati e vanno da tecniche puramente software, tipo la Address Space Layout Randomization oppure lo Stack Protector di gcc a tecniche assistite dall hardware, tipo il noto execute disable bit (XD) implementato nelle recenti CPU Intel e AMD. Nella stragrande maggioranza dei casi attaccare tramite l iniezione di codice malevolo comporta l esecuzione di chiamate di sistema estranee al normale flusso d esecuzione di un programma: per lanciare una shell ad esempio è necessario eseguire almeno una execve(). In Solaris è esistito un buffer overflow nel comando ping (CVE ) che permetteva appunto l esecuzione di codice arbitrario. Tale comando necessita di usare le raw socket, che però possono essere aperte solo dal superutente: ping quindi era installato setuid root e dunque anche il codice iniettato veniva eseguito a privilegi elevati. Ora è chiaro che se ping esegue una execve, questo è un evento del tutto anomalo perché per svolgere le sue funzioni il comando in questione non ha bisogno di lanciare in esecuzione alcun processo. Avendo questa

15 1.2. Obiettivo del lavoro 5 informazione diventa quindi possibile approntare un semplice sistema che osserva le chiamate di sistema e se non sono pertinenti prende provvedimenti quali impedirle o addirittura uccidere il processo dal quale sono state fatte. Già a metà degli anni 90 ci si è resi conto che l osservazione delle chiamate di sistema effettuate da un programma durante la sua esecuzione è un buon modo per capire se il suo comportamento è normale o meno. In [9] ad esempio viene proposto un semplice metodo che, osservando le ultime tre chiamate di sistema effettuate da un processo, è in grado di stabilire con buona approssimazione se il suo comportamento è anomalo. Negli anni successivi sono stati proposti svariati nuovi metodi basati sulle più disparate tecniche, sia statiche che dinamiche. Di queste ultime molte di esse sono di tipo probabilistico, molte di esse si basano su analisi più formali. Le più recenti tecniche dinamiche presenti in letteratura sono in grado di ricostruire una parte significativa del control flow di un programma. Successivamente queste tecniche sono state applicate con successo a sistemi virtualizzati, permettendo di monitorare le attività dei processi in modo completamente invisibile dall interno della macchina virtuale [15]. Presto ci si è resi conto che osservare soltanto qual era la system call effettuata era limitativo e si è iniziato a prendere in considerazione anche i parametri. Anche in questo caso sono state proposte idee molto diverse, prevalentemente di tipo statistico. Recentemente però è stato proposto un modello in grado di apprendere il data flow tra le chiamate di sistema. 1.2 Obiettivo del lavoro Il lavoro presentato in questa tesi è centrato proprio sull anomaly detection basata sull osservazione delle system call. Tra i vari modelli che si possono costruire a questo scopo ne esistono alcuni basati su automi o su grafi, che si differenziano per la loro precisione nel rappresentare il control flow del programma. Dal lato data flow i modelli sono invece tutt altro che numerosi. In questa tesi verranno prese in considerazione entrambe le tipologie di modelli, verranno studiate le loro possibilità sia considerando i modelli presi singolarmente sia se integrati tra di loro (control flow + data flow) e verranno evidenziate delle debolezze. Verrà quindi proposto un nuovo modello integrato che cerca di superarle.

16 6 1. Introduzione 1.3 Struttura della tesi La tesi si sviluppa in 4 ulteriori capitoli oltre a quello presente. Nel secondo capitolo verranno esaminati alcuni modelli per il control flow presenti in letteratura, sia costruiti dinamicamente che staticamente. Verranno mostrate le tecniche necessarie alla loro costruzione e verranno discussi vantaggi e svantaggi dei modelli. Finita la discussione dei modelli control flow si osserverà come la protezione di quest ultimo non sia sufficiente a impedire che un processo venga attaccato e verrà mostrato un semplice programma che è vulnerabile ad un attacco che permette di ottenere una shell senza che il suo control flow sia alterato. Si osserverà quindi che è necessario proteggere anche il data-flow e dopo una breve discussione verrà presentato un modello in grado di apprendere relazioni tra i parametri delle chiamate di sistema, anch esso presente in letteratura. Il terzo capitolo si aprirà vedendo come anche unendo un execution graph (uno dei più potenti modelli control flow) con il modello data flow si possa comunque trovare dei casi in cui è possibile attaccare il sistema senza essere scoperti. Si osserverà quindi che questo è dovuto principalmente a due motivi che sono dati da un basso accoppiamento tra i due modelli e dalla relativa povertà delle informazioni data flow raccolte. Il modello data flow può infatti trarre notevole vantaggio da informazioni già raccolte per la costruzione del modello control flow, inoltre verrà data la capacità al modello data flow di apprendere delle alternative. Senza il loro apprendimento vi sono casi in cui l informazione raccolta è veramente povera. Si proporrà dunque un nuovo modello integrato per control flow e data flow in grado di risolvere i problemi osservati, assieme a tutti gli algoritmi necessari a costruirlo. Il quarto capitolo tratterà l implementazione. In una prima parte verrà analizzato il framework DTrace che permetterà la raccolta dati necessaria alla costruzione del modello. Dopo aver visto come specificare quali dati si vuole raccogliere si passerà ad alcuni dettagli di libdtrace(3lib), necessaria per l interfacciamento low-level al framework e per l estrazione dei dati raw. Verranno poi trattati alcuni dei dettagli implementativi salienti del sistema e infine, in modo del tutto informale, si discuterà sulla complessità computazionale del modello, sia dal punto di vista del training sia dal punto di vista della verifica online. Il quinto capitolo è dedicato alle conclusioni e alla descrizione dei possibili sviluppi futuri di questo lavoro. In particolare saranno proposte tre possibili estensioni. La prima cerca di spremere ulteriormente i dati già raccolti per la costruzione del modello per carpire più informazioni sulla struttura interna del programma. La

17 1.3. Struttura della tesi 7 seconda parte dall osservazione che questi modelli sono totalmente ciechi di fronte al denial of service e quindi la proposta in questo caso è di aggiungere una dimensione statistica al modello che vada in questa direzione. La terza idea è quella di cercare di costruire il modello control flow staticamente invece che dinamicamente, in modo che il compilatore oltre a restituire l eseguibile restituisca un modello della sua struttura che verrà successivamente controllato a runtime.

18 8 1. Introduzione

19 2 Modelli per l anomaly detection In questa tesi si è interessati al rilevamento e alla conseguente segnalazione di comportamenti anomali tenuti da parte di un processo in esecuzione su un elaboratore. Questo obiettivo prevede innanzitutto il possesso di un modello del comportamento del processo e successivamente la capacità di verificare che il processo, durante l esecuzione, si comporti conformemente al modello (Figura 2.1). Offline Online Processo Processo Eventi Eventi Algoritmo di apprendimento Modello Motore di verifica del modello Figura 2.1: Architettura generale di un sistema black-box. In letteratura si possono trovare decine di metodologie volte alla costruzione di modelli per l anomaly detection basate su idee anche molto differenti tra di loro. La distinzione fondamentale però è forse quella tra metodologie white-box e black-box. Le prime prevedono di avere a disposizione il codice sorgente (o anche il binario) del programma in modo da poterlo analizzare staticamente e costruire un modello. Le seconde invece prevedono esclusivamente l osservazione dell esecuzione di un programma e, in base agli eventi generati, costruiscono un modello.

20 10 2. Modelli per l anomaly detection Le tecniche white-box e black-box hanno entrambe vantaggi e svantaggi: se per esempio si è interessati alla struttura del programma è difficile ricostruirla solo guardandone varie esecuzioni. Se ci sono dei rami di codice morto per un sistema black-box è impossibile scoprirli, mentre per un sistema white-box è immediato. Tuttavia, come vedremo, anche dalle sole osservazioni (a patto di eseguirle correttamente) è possibile ottenere un incredibile quantità di informazioni. Una delle molte situazioni in cui invece le tecniche black-box sono avvantaggiate è ad esempio quella in cui si sta osservando dove si trovano i file che una chiamata ad open() apre: se in un numero ragionevolmente grande di osservazioni si vede che i file stanno tutti in una data directory dir si può affermare che quella open() deve aprire solo file che stanno in dir. Questa, non conoscendo la struttura interna del programma osservato è sicuramente un informazione tutt altro che certa ma nonostante l incertezza è comunque un informazione che l analisi statica nella maggioranza dei casi non può dare. In questa tesi si cercherà di modellare per via black-box sia il control flow del programma che il data flow. Verranno prese in considerazione diverse tecniche già note, le quali però in certi contesti presentano delle debolezze e dunque l obiettivo è di migliorarle e di combinarle in modo da eliminare i problemi che presentano, ottenendo un modello in grado di rilevare un numero maggiore di attacchi. 2.1 Modelli control flow I modelli che analizzeremo in questa sezione sono basati sulla descrizione di proprietà che riguardano il flusso di controllo di un programma. Analizzando gli eventi che si osservano a runtime è possibile costruire degli automi che rappresentano in modo più o meno fine le transizioni ammesse per un dato programma Automi a stati finiti Il modello di automi a stati finiti sicuramente più interessante è stato proposto in [21]. Gli autori osservano come tutti i modelli precedenti abbiano problemi o limitazioni più o meno gravi, o di carattere computazionale [10, 18] o dovute al fatto che semplicemente è stata proposta una metodologia che poco si presta all implementazione [12] e propongono una tecnica molto veloce per apprendere un automa in grado di rilevare una consistente categoria di attacchi. L automa viene costruito a partire da una o più tracce ottenute dall osservazione del sistema. Ogni traccia è composta da un certo numero di eventi, rappresentabili

21 2.1. Modelli control flow 11 con una coppia (s i, p i ). Ogni evento contiene due informazioni e in particolare la chiamata di sistema che è stata eseguita e il punto del programma dal quale è stata eseguita. L automa è rappresentabile come un grafo G = (V {end}, E = V V L) e, dati due eventi consecutivi (s i, p i ) e (s i+1, p i+1 ) di una traccia di lunghezza k, la costruzione avviene nel seguente modo: per 0 i k: V = V {p i } per 0 i k: E = E {(p i, p i+1, s i )} infine: E = E {(p k, end, s k )} L idea dietro a questo automa è che per passare da uno stato ad un altro del programma deve avvenire una transizione causata da una chiamata di sistema. Intuitivamente, questa costruzione porta quindi ad un automa in cui gli stati sono etichettati con il punto del programma dal quale viene eseguita la system call e gli archi con la chiamata di sistema coinvolta nella transizione. Vediamo un esempio. 1 void f(int cond) 2 { 3 open(); 4 if (cond % 2) 5 read(); 6 else 7 write(); 8 close(); 9 } int main(void) 12 { 13 int i = 3; 14 while (i--) 15 f(i); 16 } La traccia di una esecuzione del programma d esempio sarebbe la seguente: (open, 3), (write, 7), (close, 8), (open, 3), (read, 5), (close, 8), (open, 3), (write, 7), (close, 8)

22 12 2. Modelli per l anomaly detection open 5 read 3 open 7 write 8 close end close Figura 2.2: FSA d esempio. che da luogo agli insiemi V ={3, 5, 7, 8, end} E ={(3, 5, open), (3, 7, open), (5, 8, read), (7, 8, write), (8, 3, close), (8, end, close)} corrispondenti all automa rappresentato in Figura VtPath VtPath [6] è un metodo che migliora gli FSA, andando a guardare l intero user space stack del processo nel momento della chiamata di sistema invece di osservare soltanto il punto del programma in cui la chiamata è stata fatta. Questo sistema si basa sul concetto di virtual path, di seguito delineato. Siano A = {a 1,..., a n } e B = {b 1,..., b m } gli stack osservati in due system call consecutive. Essi vengono confrontati finché non si trova un indice l tale che a l b l. A questo punto si definisce il path tra le due system call come: P = a n Exit;... ; a l+1 Exit; a l b l ; Entry b l+1 ;... ; Entry b m Entry ed Exit sono dei nodi fittizi che rappresentano rispettivamente il punto d ingresso e il punto d uscita di una funzione. Questi path vengono appresi durante il training e, a training completato, vengono utilizzati per verificare il corretto comportamento del programma. Possono generarsi differenti anomalie, in particolare: Stack anomaly, se lo stack osservato non è tra quelli appresi durante il training Return address anomaly, se uno qualunque dei return address sullo stack non è corretto rispetto a quelli osservati durante il training System call anomaly, se la system call eseguita non è corretta

23 2.1. Modelli control flow 13 Virtual path anomaly, se non è possibile trovare il percorso effettuato tra quelli appresi Execution graphs Gli execution graphs costituiscono forse il più potente modello control flow presente in letteratura ottenuto con tecniche black-box [7] ed è uno dei due componenti da cui si è partiti per sviluppare il modello presentato in questa tesi. L obiettivo dell execution graph è quello di ottenere, osservando le esecuzioni di un programma, un modello che accetta le stesse sequenze di chiamate di sistema che sarebbero accettate da un modello basato sul control flow graph, quindi costruito staticamente. Naturalmente questo non è possibile perché nel codice potrebbero esserci dei rami morti, rilevabili solo a tempo di compilazione. Tuttavia utilizzando solo tecniche black-box si riesce a costruire un execution graph con due proprietà molto importanti: accetta solo sequenze di chiamate di sistema che sono consistenti con il control flow graph del programma il linguaggio accettato dall execution graph è massimale rispetto ai dati appresi durante il training: in altre parole ogni estensione dell execution graph potrebbe far passare inosservati degli attacchi Definizione 1 (Osservazione ed esecuzione) Un osservazione è una n-pla di interi positivi r 1, r 2,..., r k con k > 1. Un esecuzione è una sequenza di lunghezza arbitraria di osservazioni. In particolare in un osservazione r 1, r 2,..., r k, r 1 è un indirizzo in main(), r k 1 è il return address corrispondente all istruzione che esegue la system call ed r k è il numero corrispondente alla system call eseguita. In altre parole un osservazione è una fotografia dello stack del processo al momento in cui viene eseguita una system call. Definizione 2 (Execution graph, foglia, crs ) Un execution graph per un insieme di esecuzioni X è un grafo EG(X ) = (V, E call, E crs, E ret ) in cui V è un insieme di nodi mentre E call, E crs, E ret V V sono insiemi di archi diretti, definiti come segue: