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

22 2. Modelli per l’anomaly detection
esempio il problema dell’impossible path) e questo è causato dall’eccessiva semplicità
del modello.
L’execution graph invece può certamente generare falsi positivi, quindi riconosce-
re come attacchi sequenze di stack che non lo sono (e questo è causato di nuovo dal
training insufficiente), ma le successioni di stack che ammette sono tutte ammesse
anche dal control flow graph.
Modello Costruzione Relazione con CFG
FSA Dinamica né ⊆ né ⊇
VtPath Dinamica né ⊆ né ⊇
Execution graph Dinamica Dimostrato formalmente ⊆
Abs. Stack Statica = per costruzione
Tabella 2.1: Caratteristiche dei modelli.
Il modello FSA è estremamente semplice e se l’automa viene costruito con l’op-
portuna cura si rivela efficace contro una discreta quantità di attacchi. Un buffer
overflow per esempio, fatto nel modo standard [17], viene rivelato senza grossi pro-
blemi. Anche l’implementazione di un IDS basato su questa tecnica non presenta
difficoltà, se non quelle legate alla gestione di fork ed exec [21]. La semplicità del
modello però è anche la sua debolezza ed è facile immaginare casi in cui l’automa
non è in grado di osservare comportamenti anomali. Uno di questi casi è quello
dell’impossible path. Supponiamo che in un programma ci sia una funzione f() e
che il codice al suo interno sia vulnerabile ad un buffer overflow: l’attaccante po-
trebbe modificare il return address di f() in modo da farla ritornare in un punto
diverso da quello di chiamata (il codice di Figura 2.3 potrebbe essere un esempio di
questo scenario, si entra da riga 4 e si esce da riga 6). Questo modello è totalmente
cieco a questo tipo di attacco e questa è una mancanza grave, in quanto il codice
tra le due invocazioni di f() potrebbe essere ad esempio quello che verifica delle
credenziali e consente o meno l’accesso al sistema.
Il modello VtPath si avvicina all’execution graph e per come è costruito è ve-
rosimile che le stringhe di system call che accetta sono un sottoinsieme di quelle
che sarebbero accettate dal control flow graph, questo fatto però non è provato
formalmente dagli autori.
Il modello dell’execution graph infine è sicuramente quello più interessante pro-
prio per il fatto che è stato relazionato formalmente con il control flow graph, mo-
strando che le stringhe riconosciute sono contenute in quest’ultimo. Questo significa
che possono esserci casi in cui l’execution graph riconosce come illecita un’azione