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

Recommendations

Info

18 2. Modelli per l’anomaly detection possibile e realistico costruire degli attacchi (non-control data attacks) che non hanno bisogno di portare il sistema ad eseguire codice malevolo. Dal loro studio emerge che oltre ad essere perfettamente possibile, la gravità degli attacchi non-control data è equivalente a quella dei più classici control-data. In [4] vengono identificate 4 classi di dati critici per la sicurezza del software: • dati di configurazione • input dell’utente • identità dell’utente • dati di decision-making 1 #define STRSZ 32 2 3 int authenticate(char *user, char *password) { 4 if ( (strncmp(user, "matteo", STRSZ) == 0) && 5 (strncmp(password, "pippo123", STRSZ) == 0) ) 6 return 1; 7 8 return 0; 9 } 10 11 int main(void) { 12 int authenticated = 0; 13 char user[32], password[32]; 14 15 gets(user); 16 gets(password); 17 18 if ( authenticate(user, password) ) 19 authenticated = 1; 20 21 if (authenticated) system("/bin/sh"); 22 else printf("Not allowed\n"); 23 } Figura 2.6: Banale programma vulnerabile ad un non-control data attack. Delle quattro l’ultima è sicuramente la più interessante: vi sono alcuni dati che sono necessari affinché un programma decida che azione intraprendere e, riuscendo a corromperli, è possibile portare un programma a fare qualcosa di contrario rispetto a ciò che andrebbe fatto. Prendiamo ad esempio il programma di Figura 2.6: il
2.2. Modelli data flow 19 suo scopo è autenticare un utente su un sistema e per farlo utilizza una procedura authenticate() (che potrebbe essere di complessità arbitraria). Se l’autenticazione ha successo viene impostato un flag per ricordarlo ed il programma può procedere. L’uso non sicuro di gets() permette però ad un utente malintenzionato di impostar- lo ad un valore diverso da zero e, anche se l’autenticazione non ha successo, l’accesso al sistema viene garantito. Al di là del fatto che gets() è qualcosa di talmente pericoloso che se viene usata viene generato un warning dal compilatore, in un caso come questo un IDS potrebbe verificare i valori di ritorno delle read() provocate dalle gets() ed, essendo anomali, uccidere il processo. È notevole fino a dove ci si sia spinti con attacchi classificabili come non-control data: in [3], provocando fallimenti casuali all’hardware e dunque errori nelle com- putazioni, è stato mostrato come sia possibile rendere del tutto vulnerabili alcuni codici crittografici, RSA compreso. necessario proteggere anche il data flow. 2.2.1 Un modello data flow È dunque chiaro come, oltre al control flow, sia Nel tempo diversi sono stati i tentativi di utilizzare anche i parametri nel rilevamento di comportamenti anomali [13, 22, 8] e gli approcci utilizzati sono stati prevalen- temente statistici. Un modello notevole però è quello proposto in [2]. Gli autori mostrano una tecnica che permette di apprendere delle relazioni tra i parametri delle system call. Ad esempio, se viene eseguita una open() ed il file descriptor da essa restituito viene usato da una successiva read() e da una successiva close(), il sistema è in grado di apprendere che il valore del file descriptor tra le tre chiamate deve essere uguale. Il sistema è in grado di apprendere sia relazioni unarie, ovvero che valgono pun- tualmente su un singolo argomento, sia binarie, ovvero che valgono tra due argomenti differenti. Algoritmo 1: Algoritmo del modello data flow. learnRelations(EvArg X, Value V); Y = lookup(V ); CurRels[R][X] = CurRels[R][X] ∩ Y; Yn = Y ∩ NewArgs(X); CurRels[R][X] = CurRels[R][X] ∪ Yn; update(X, V );
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: 2.2. Modelli data flow 17 • se v
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?