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

2.2. Modelli data flow 17
• se v è Exit(f) semplicemente si rimuove v
• se v non riguarda una chiamata di funzione ma una system call si toglie v e si
inserisce s ∈ Σ e non-deterministicamente si sceglie w : (v, w) ∈ E e si inserisce
w
Se invece s si trova sulla cima dello stack si verifica che s = s ′ , dove s ′ è il simbolo
corrente dell’input. Se l’uguaglianza è verificata si estrae s dallo stack e si procede,
altrimenti si entra in uno stato d’errore che viene segnalato.
2.2 Modelli data flow
I precedenti modelli visti focalizzano la loro attenzione esclusivamente sul flusso di
controllo del programma, senza tenere in alcuna considerazione i dati (ovvero i pa-
rametri) coinvolti nelle chiamate di sistema. Tuttavia monitorare anche i parametri
si rivela di notevole importanza. Si prenda ad esempio un attacco che sfrutta una
race condition del tipo TOCTTOU (Time of check to time of use) dove una risorsa
riferita da un nome cambia tra il momento in cui viene fatto un test e il momento
in cui viene usata (si veda l’esempio di Figura 2.5). In un attacco come questo le
chiamate di sistema fatte da un programma sono sempre le stesse ma l’interpreta-
zione dei loro parametri in un momento piuttosto che in un altro è completamente
diversa.
if (access("file", W_OK) != 0) {
exit(1);
}
/* In questo esatto momento in un altro processo un
attaccante esegue symlink("/etc/passwd", "file"); */
fd = open("file", O_WRONLY);
write(fd, buffer, sizeof(buffer));
Figura 2.5: Time to check to time of use.
Un altro scenario è quello delineato in [4]. Gli autori notano che chi attacca
un sistema attualmente è concentrato su metodologie che portano il processore ad
eseguire codice in qualche modo estraneo al programma (control data attacks: buffer
overflow, heap overflow, return-to-libc,... ricadono in questa categoria). Da questa
osservazione si chiedono se, nel momento in cui il control flow è protetto, diventa