Un modello integrato control-flow e data-flow per il rilevamento ...

Recommendations

Info

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 semi- automatica 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 ma- levolo comporta l’esecuzione di chiamate di sistema estranee al normale flusso d’e- secuzione di un programma: per lanciare una shell ad esempio è necessario eseguire almeno una execve(). In Solaris è esistito un buffer overflow nel comando ping (CVE-1999-0056) 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 inietta- to 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
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.
Page 1: Università degli Studi di Udine Fa
Page 5 and 6: Ringraziamenti In questo percorso m
Page 7 and 8: Indice 1 Introduzione 1 1.1 Anomaly
Page 9 and 10: Elenco delle figure 1.1 Codice sema
Page 11 and 12: 1 Introduzione Dai tempi della “d
Page 13: 1.1. Anomaly detection e system cal
Page 17 and 18: 1.3. Struttura della tesi 7 seconda
Page 19 and 20: 2 Modelli per l’anomaly detection
Page 21 and 22: 2.1. Modelli control flow 11 con un
Page 23 and 24: 2.1. Modelli control flow 13 • Vi
Page 25 and 26: 2.1. Modelli control flow 15 1 int
Page 27 and 28: 2.2. Modelli data flow 17 • se v
Page 29 and 30: 2.2. Modelli data flow 19 suo scopo
Page 31 and 32: 2.3. Discussione dei modelli studia
Page 33 and 34: 2.3. Discussione dei modelli studia
Page 35 and 36: 3 Un modello che integra control fl
Page 37 and 38: 3.1. Debolezze dei modelli esistent
Page 45 and 46: 3.2. Proposta 35 1 int main(void) 2
Page 47 and 48: 3.3. Costruzione del modello 37 mai
Page 49 and 50: 3.3. Costruzione del modello 39 Un
Page 51 and 52: 3.3. Costruzione del modello 41 Tra
Page 53 and 54: 3.3. Costruzione del modello 43 Par
Page 55 and 56: 3.3. Costruzione del modello 45 Tut
Page 57 and 58: 3.5. L’algoritmo per la verifica
Page 59 and 60: 3.5. L’algoritmo per la verifica
Page 61 and 62: 4 L’implementazione L’implement
Page 63 and 64: 4.2. Introduzione a DTrace 53 un ce
Page 65 and 66:
4.2. Introduzione a DTrace 55 1 sta
Page 67 and 68:
4.3. Implementazione del sistema 57
Page 69 and 70:
4.4. Costo computazionale del model
Page 71 and 72:
4.4. Costo computazionale del model
Page 73 and 74:
5 Conclusioni e sviluppi futuri La
Page 75 and 76:
5.2. Sviluppi futuri 65 5.2.1 L’u
Page 77 and 78:
5.2. Sviluppi futuri 67 sistemi. In
Page 79 and 80:
Bibliografia [1] System V Applicati
show all

Un modello integrato control-flow e data-flow per il rilevamento ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?