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

Recommendations

Info

26 3. Un modello che integra control flow e data flow “la funzione log event() può scrivere nel log-file che un utente ha fallito l’autenticazione oppure che un client ha inviato una richiesta malformata”. Questo permette ad un ipotetico attaccante di costruire attacchi tali che il programma, pur rimanendo all’interno del control flow ammesso, riporti informazioni diverse da quelle che normalmente dovrebbe riportare. Nel contesto di un processo industriale critico, questo potrebbe rappresentare un notevole problema. Sarebbe ideale quindi riuscire a far si che le informazioni data flow che vengono apprese siano qualcosa di più dettagliato, qualcosa del tipo “la funzione log event(), se chiamata dal codice che si occupa dell’autenticazione può scrivere nel log-file che un utente ha inserito la password errata, mentre se chiamata dal codice di dialogo col client può scrivere che un client ha inviato una richiesta malformata”. L’osservazione fondamentale che consente questo miglioramento è che una chiamata di sistema è caratterizzata in modo molto più preciso se, invece di considerare soltanto la sua posizione assoluta nel codice, si considera anche il contesto in cui è eseguita, ovvero la sequenza di record di attivazione che la precedono sullo stack. Nei due casi si osserveranno sequenze differenti e questo consente di capire che si è arrivati a log event() da due strade diverse. L’informazione relativa allo stack viene già raccolta per la costruzione dell’execution graph e dunque vale la pena far si che ne benefici anche il modello data flow. In questo modo, per un ipotetico IDS costruito con queste tecniche, è immediato capire da dove proviene la richiesta di inserire un messaggio nel log-file e quindi capire se quel messaggio è lecito oppure no. Vediamo, nella pratica, come può presentarsi questo scenario. 3.1.1 Primo scenario: vulnerabilità nel codice Nel programma della Figura 3.1 è presente un evidente buffer overflow, dovuto al- l’uso non sicuro della funzione strcpy(). Il buffer overflow permette di eseguire codice arbitrario e, nel caso il programma sia installato setuid root, permette ad un attaccante di prendere il controllo completo del sistema. Un attacco tramite buffer overflow fatto nel modo standard tuttavia viene immediatamente rilevato anche dal più semplice FSA (Figura 3.2). Quello che però l’FSA non può rilevare è un attacco che, iniettando codice opportuno in buf, esegue un numero arbitrario di chiamate a put str() (e quindi a write) con parametri arbitrari. Le cose non migliorano di
3.1. Debolezze dei modelli esistenti 27 1 #include 2 3 void put_msg(char *msg) 4 { 5 write(1, msg, strlen(msg)); 6 } 7 8 void g(void) 9 { 10 put_msg("Hello,"); 11 } 12 13 void f(char *path) 14 { 15 char buf[128]; /* Il programmatore non ha usato MAX_PATH! */ 16 strcpy(buf, path); 17 /* ... qualcosa che non siano system calls ... */ 18 } 19 20 int main(void) 21 { 22 char *path = chiedi_nome_file(); /* read() */ 23 f(path); 24 g(); 25 put_msg("world\n"); 26 } Figura 3.1: Programma vulnerabile d’esempio. 22 read write 5 write end Figura 3.2: FSA per il primo esempio.
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 and 14: 1.1. Anomaly detection e system cal
Page 15 and 16: 1.2. Obiettivo del lavoro 5 informa
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: 3 Un modello che integra control fl
Page 39 and 40: 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

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?