Buffer Overrun Detection using Linear Programming and Static Analysis

1. Buffer Overrun Detectionusing Linear Programmingand Static Analysis Prevedere il Buffer Overrun usando Programmazione Lineare e Analisi Statica Analisi e Verifica di Programmi Alberto De Lazzari - Fabio Pustetto

2. Introduzione • Scrivere oltre i limiti di un buffer in memoria • C permette la manipolazione diretta dei puntatori senza alcun tipo di controllo sui limiti • Dati validi possono essere sovrascritti • Hacker sfruttano per eseguire codice malvagio • Caricato in memoria come valido • acquisizione dei privilegi di root • Gli approcci per rilevare il buffer overrun possono essere di tipo • Statico • esamina il codice sorgente per eliminare questo tipo di bug prima che il codice sia distribuito • Dinamico • previene gli “attacchi” basati sul bug • perciò non sono eliminati come nell’analisi statica • generalmente causano il crash dell’applicazione quando è rilevato un attacco • Controlli ridondanti portano ad overhead

3. Linee Guida: La definizione e l’implementazione del tool che permette l’analisi statica del codice, si divide nei seguenti punti: • Uso di analisi statica per modellare stringhe di codice C sorgente come programma lineare • Definizione e implementazione di risolutori veloci e scalabili basati su tecniche innovative della programmazione lineare. La soluzione al programma lineare determina i limiti del buffer • Tecniche per rendere l’analisi del programma sensibile al contesto • Efficacia di altre tecniche di analisi come il partizionamento statico per eliminare bug dal codice sorgente -> tool deve essere scalabile

4. Tecniche dinamiche: approfondimento • Proteggere l’indirizzo di ritorno sullo stack • controllo d’integrità sui record evitando la modifica dell’indirizzo di ritorno • si può rilevare e prevenire un attacco di tipo stack smashing • Corrompere lo stack scrivendo oltre la sua fine, permettendo di cambiare l’indirizzo di ritorno di una funzione • Altre tecniche generalizzano il concetto precedente estendendolo a puntatori, variabili locali e argomenti di funzioni • Proteggere tutti gli accessi ai puntatori • cifrandoli quando sono memorizzati • decifrandoli quando sono caricati nei registri della CPU • non evita la possibilità di distruggere il puntatore • impedisce di ottenere un valore di puntatore prevedibile in memoria • non si conosce la chiave di decifratura

5. Tecniche statiche: approfondimento • suddivise in tre classi • tool guidati da annotazioni • utilizza annotazioni date dall’utente • Es: pre/post-condizioni di una funzione • tool che usano l’analisi simbolica • tool che estraggono un modello dal codice sorgente e lo utilizzano per rilevare la presenza di bug

6. tool guidati da annotazioni • CSSV converte un programma in C in un programma intero, con asserzioni di correttezza incluse e usa un algoritmo di analisi statica conservativa per trovare manipolazioni erronee sugli interi che direttamente si traducono in bug sul codice C. • L’analisi è fatta sulla base di annotazioni (chiamate contract) che sono usate per rendere l’analisi interprocedurale • Split è simile a CSSV anche se usa un’analisi flow-sensitive e pre/post-condizioni fornite dall’utente.

7. tool che usano l’analisi simbolica • Alcuni tool (Archer, ARray CHeckER) eseguono il codice in maniera • Simbolica • permette di analizzare il codice senza conoscere l’esatto valore delle variabili che si stanno manipolando • Interprocedurale • permette di trattare una stessa variabile che si trova in metodi diversi • mantenendo l’informazione riguardo alle variabili in un database man mano che l’esecuzione procede • l’esecuzione di statement può portare alla modifica dello stato del programma • quando in uno statement si accede ad un buffer, Archer controlla, attraverso il database, se l’accesso avviene nel rispetto dei limiti del buffer

8. tool che estraggono un modello dal codice sorgente e lo utilizzano per rilevare la presenza di bug • Si estrae un modello dal codice sorgente • Si modellano le stringhe come tipi di dato astratto e si trasforma il rilevamento del buffer overrun in un problema di analisi sul range di valori interi • Il tool presentato in questo paper rientra in questa classe di tecniche introducendo un’analisi dei puntatori più precisa

9. Architettura complessiva • plug-in per CodeSurfer • tool utilizzato per la comprensione del codice • costruisce una rappresentazione totale del programma attraverso • grafo delle dipendenze di sistema composto dai grafi di dipendenza di ciascuna procedura • grafo del controllo del flusso interprocedurale • alberi di sintassi astratta per le espressioni del programma • informazioni sui puntatori • Slicing • partizionamento di un programma • Tecnica per visualizzare le dipendenze • restringe l’attenzione alle componenti di un programma rilevanti per la valutazione di espressioni • backward slicing / forward slicing

10. Generazione dei vincoli … • buf: puntatore a buffer modellato da 4 variabili di vincolo: • buf!alloc!max • buf!alloc!min • numero massimo e minimo di byte allocati per il buffer buf • buf!used!max • buf!used!min • numero massimo e minimo di byte usati da buf • i: variabile intera, modellata da 2 variabili di vincolo • i!max • indica il massimo valore di i • i!min • denota il minimo valore di i • I vincoli modellano il programma in maniera • non sensibile al flusso • ignora l’ordine degli statement • non sensibile al contesto • non fa differenze per molteplici punti di chiamata, alla stessa funzione

11. … • 4 statement generano vincoli • dichiarazioni di buffer • assegnamenti • chiamate a funzione • statement di ritorno • Es: alla riga 17 del codice • strcpy(copy,buffer) • Risultano i vincoli (associati ai puntatori dei buffer): • copy!used!max ≥ buffer!used!max • copy!used!min ≤ buffer!used!min

12. … alcuni chiarimenti • Poiché è ignorata l’analisi di flusso, i predicati come counter < 10 sono ignorati • Se generiamo un vincolo del tipo counter!max ≥ counter!max + 1 (generato da counter++), questo non può essere interpretato da un risolutore di programmi lineari • dunque questo statement è modellato trattandolo come due statement: counter’ = counter + 1 e counter = counter’. I due vincoli catturano il fatto che il puntatore è incrementato di uno e sono accettabili dal risolutore, anche se il programma lineare risultante sarà non ammissibile • Una variabile di programma che ottiene il suo valore dall’ambiente o dall’input dell’utente in un modo non controllato, è considerata insicura • Se consideriamo, ad esempio, lo statement getenv(“PATH”), che ritorna il percorso di ricerca, può ritornare una stringa arbitrariamente lunga. Per riflettere il fatto che la stringa può essere arbitrariamente lunga, sono generati dei vincoli del tipo getenv$return!used!max ≥ +∞ e getenv$return!used!min ≤ 0. Allo stesso modo, una variabile intera i inserita dall’utente genera i vincoli: i!max ≥ +∞ e i!min ≤ -∞

13. Analisi di alterazione • Vincoli generati, passati al modulo di analisi di alterazione • Scopo: ottenere dei vincoli che siano successivamente utilizzabili dal risolutore • Solo valori finiti • 2 passi • Identificare e rimuovere variabili che danno valore infinito • Identifica e rimuove variabili di vincolo non inizializzata • il sistema di vincoli è esaminato per vedere se • vincoli di tipo max hanno un estremo inferiore finito • vincoli di tipo min hanno un estremo superiore finito • Requisito non soddisfatto se • non sono state inizializzate nel codice sorgente • gli statement che influiscono sulle variabili di programma non sono state catturate dal generatore di vincoli • => non esiste modello per funzioni di librerie

14. Risoluzione dei vincoli… • si utilizza la programmazione lineare • modella e manipola nuovi tipi di vincoli • garantisce correttezza dei risultati • Un programma lineare e' un problema di ottimizzazione: minimizza cTx riferito a Ax ≥ b • A matrice m x n di costanti • b e c vettori di costanti • x è vettore di variabili • sistema di m disequazioni in n variabili, necessarie per trovare i valori delle variabili che soddisfano i vincoli e minimizzano la funzione obiettivo cTx, nel campo dei numeri reali finiti.

15. … • Insieme di vincoli ottenuti dopo l'analisi è insieme di vincoli lineari • si può allora formulare come problema di programmazione lineare • Obiettivo: ottenere i valori • buf!alloc!max • buf!alloc!min • buf!used!max • buf!used!min • che rendono la differenza tra byte allocati e byte usati dal puntatore al buffer buf più piccola possibile, rispettando i vincoli • se tutte le variabili max hanno minimo finito e tutte le variabili min hanno massimo finito, vale che: • min Σbuf (buf!alloc!max - buf!alloc!min + buf!used!max - buf!used!min)

16. … • Trovare soluzioni intere è Programmazione Lineare Intera: problema NP-completo ben conosciuto • NP = è noto un algoritmo che termina in tempo polinomiale rispetto alla dimensione dei dati • NP-hard = un algoritmo per risolvere uno di questi problemi può essere convertito in un algoritmo per risolvere un qualunque problema NP • NP-completi = sia NP che NP-hard • programma lineare ammissibile • si trovano valori finiti per tutte le variabili (rispettando i vincoli) • soluzione ammissibile è ottima • se massimizza (o minimizza) il valore della funzione • programma lineare inammissibile • se non ha soluzioni ammissibili

17. … • soluzione ottima per determinare i limiti del buffer • nessun programma può essere illimitato • vincoli esaminati dall'analizzatore di alterazione • tutte le variabili max della funzione obiettivo hanno limite inferiore finito • Minimizzando le variabili max otterremo ancora valori finiti • Similmente per min • se programma lineare non ha soluzioni ammissibili • non si può assegnare arbitrariamente dei valori finiti alle variabili per ottenere soluzioni ammissibili • Es: settare tutte le variabili di max a +∞ e quelle di min a -∞ => ci sarebbero troppi falsi allarmi! • approccio in cui si rimuovere un piccolo insieme di vincoli per rendere il sistema ammissibile • noto come Irreducibly Inconsistent Set (IIS) • insieme minimale di vincoli: l'intero insieme dei vincoli di un IIS è inammissibile ma ogni sottoinsieme è ammissibile

18. Dato un insieme di vincoli determina un IIS (se esiste) e garantisce che nel caso ce ne siano più di uno almeno uno venga rilevato si può iterare l'algoritmo più volte sul risultato dell'iterazione precedente per creare il più piccolo programma lineare ammissibile da uno non ammissibile Elastic Filtering algorithm • esamina l'insieme dei vincoli C per determinare ammissibilità Se è ammissibile STOP Altrimenti -> 2 • allora esiste almeno un C’  C che è IIS • genera dopo un certo numero di iterazioni, C-C’ ammissibile • settare i valori delle variabili max e min in C' rispettivamente a ∞ e -∞ • ci sono variabili a ∞ rimuovere i vincoli alterati da queste variabili: C’’  C-C‘ D=C-C’-C”

19. Risolvere i vincoli gerarchicamente • Elastic Filtering algorithm veloce ma anche un’approssimazione • può rimuovere più vincoli di quelli necessari per avere una soluzione ammissibile • risolutore gerarchico • scomporre l’insieme dei vincoli in insiemi più piccoli e risolverli separatamente • grafo diretto aciclico (DAG) • ogni insieme di vincoli è associato a un vertice del DAG e gli archi rappresentano le dipendenze tra essi • modifica a ∞ un numero inferiore di variabili, risulta più preciso e determina dei valori precisi

20. Individuare overrun • basata sui valori restituiti dal risolutore e dai valori dell’analisi di alterazione • buffer puntato da header ha 2048 byte allocati e la sua lunghezza può variare tra 1 e 2048 byte => non si può verificare un buffer overrun => header è segnato come “sicuro”. La stessa cosa vale per buf. • buffer puntato da ptr ha un numero di byte allocati [1024..2048] mentre la lunghezza può variare [1..2048]. ptr fa parte di due statement. Alla riga (6) ptr punta ad un buffer lungo 2048 byte mentre alla riga (9) punta ad un buffer lungo 1024 byte. La non sensibilità al contesto dell’analisi significa che non possiamo fare differenze tra i due punti del programma e dunque possiamo derivare che al massimo ptr è di 2048 byte. In questo tipo di situazione in cui si verifica che • ptr!alloc!min < ptr!used!max≤ptr!alloc!max • possiamo avere un overrun. Questo però è un falso positivo dovuto alla non sensibilità del contesto dell’analisi • variabile copy: copy!alloc!max < copy!used!max e c’è un’esecuzione del programma in cui saranno scritti più byte di quelli che possono essere ottenuti • Concludiamo dunque che in questa situazione si verifica un overrun

21. Aggiungere la sensibilità al contesto • generazione dei vincoli • non è sensibile al contesto • si considera ogni punto di chiamata come un assegnamento delle variabili in input reali alle variabili in input formali e il ritorno dalla funzione come un assegnamento delle variabili in output formali alle variabili in output reali • si fondono le informazioni attraverso i punti di chiamata, ottenendo un’analisi imprecisa • 2 tecniche • constraint inlining • summary information

22. constraint inlining… • Inlining nelle funzioni • rimpiazza una chiamata di funzione con un’istanza del corpo della funzione • gli argomenti reali sono sostituiti a quelli formali • eseguita a tempo di compilazione • crea una nuova istanza dei vincoli della funzione chiamata ad ogni punto di chiamata • Se non sensibile al contesto • si trattano differenti punti di chiamata ad una funzione, in modo identico Ad ogni punto di chiamata di una funzione, produciamo i vincoli per la funzione con le variabili locali e i parametri formali, rinominati unicamente per quel punto di chiamata

23. … • La sensibilità al contesto si può ottenere modellando ciascun punto di chiamata alla funzione come un insieme di assegnamenti di istanze rinominate delle variabili formali • un assegnamento per ciascun parametro in input formale rinominato della funzione • allevia il problema di unire le informazioni attraverso differenti chiamate alla stessa funzione • per il puntatore cc1 otteniamo il range [0…2047] per cc1!alloc e [1…2048] per cc1!used • per il puntatore cc2 otteniamo il range [0…1023] per cc2!alloc e [1…1024] per cc2!used • miglioramento rispetto a non sensibile al contesto, ma… • Se numero esponenziale di contesti di chiamata • il sistema di vincoli avrà un numero molto grande di variabili • ci sarà anche un grande numero di vincoli • non può funzionare con le chiamate di funzioni ricorsive

24. summary information… • supera i difetti del constraint inlining • si ottiene un “riassunto” per ciascuna funzione f per “simulare” l’effetto della chiamata • Vincoli riassuntivi • riassumono l’effetto della funzione in termini di variabili di vincolo rappresentanti variabili globali e parametri formali della funzione stessa • Es: i vincoli generati dalla funzione copy_buffer • Rimpiazzare parametri formali dei vincoli riassuntivi con quelli reali corrispondenti a ciascun punto di chiamata

25. … • Questo approccio non causa un accrescimento del numero di variabili di vincolo • è più efficiente ma meno preciso del constraint inlining • può manipolare anche le funzioni ricorsive • Es: • i valori per cc1!used, cc1!alloc, cc2!used e cc2!alloc sono gli stessi che si ottengono usando il constraint inlining • i valori di copy!alloc e copy!used sono [0…2047] e [1...2048] rispettivamente • Questo perché i valori di queste variabili ottenute dalla chiamata alla riga (7) e alla riga (10) sono “unite” • Il constraint inlining ritorna i valori [0...2047] e [1…2048] per copy!alloc e copy!used, rispettivamente per la chiamata alla riga (7) • ritorna [0…1023] e [1…1024] per la chiamata alla riga (10)

26. Sperimentazione su casi reali • Testato su • wu-ftpd (2.5.0 e 2.6.2) e sendmail (8.7.6 e 8.11.6) • Pentium 4 Xeon 3GHz, 4 GB RAM • sistema operativo Debian Linux 3.0 • CodeSurfer 1.8 e compilatore gcc-3.2.1 • risolutore gerarchico • Context insensitive • CodeSurfer per filtrare i warning • Testato per provare se riusciva a scoprire bug già conosciuti e se riusciva a scoprirne altri non conosciuti

27. Testing wu-ftpd 2.6.2 • 18mila righe di codice • tool ha segnalato 178 warning • 14 overrun mai segnalati. Eccone uno: • potenziale overrun su buffer puntato da accesspath in read_servers_line nel file rdservers.c: • 8192 byte possono essere copiati in un buffer in cui sono allocati al massimo 4095 byte • La funzione fgets può copiare fino a 8192 (dimensione di BUFSIZ) byte in buffer • hcp e acp, puntano all’interno di buffer => qualcuno può far puntare hcp o acp ad un buffer lungo fino a 8192 byte => overflow sul buffer puntato sia da accesspath sia da hostname • La procedura read_server_line è chiamata, ad es, nel main di ftprestart.c con due buffer locali, hostaddress e configdir, per i quali sono allocati 32 byte e 4095 byte, rispettivamente • La chiamata legge il contenuto del file _PATH_FTPSERVERS, che tipicamente ha accesso privilegiato • In alcune configurazioni questo file può essere scritto da un utente locale • Scegliendo dunque delle stringhe di input in maniera attenta, si può sfruttare l’overflow per ottenere accessi privilegiati

28. Testing wu-ftpd 2.5.0 • 16mila righe di codice • tool ha segnalato 139 warning • overflow su una variabile globale, mapped_path, che punta ad un buffer nella procedura do_elem nel file ftpd.c • Uso improprio di strcat(mapped_path,dir) • dir può derivata (indirettamente) dall’input dell’utente • range per mapped_path!used è [0…+∞] mentre per mapped_path!alloc è [4095…4095] • La chiamata a strcat è modellata secondo quattro vincoli lineari • I primi due vincoli rendono il programma lineare non ammissibile • risultato in dst!used!max settato a +∞ • mapped_path!used!max settato +∞

29. Testing sendmail • 8.7.6 • 38mila righe di codice • tool ha segnalato 295 warning • alcuni overflow di tipo off-by-one • si potrebbe verificare la scrittura di n+1 byte in un buffer che ha n byte allocati • 8.11.6 • 68mila righe di codice • Tool ha segnalato 453 warning • Uno coinvolge la funzione crackaddr nel file headers.c, che fa il parsing della stringa di un indirizzo e-mail • memorizza la stringa dell’indirizzo in un buffer statico locale, buf lungo MAXNAME + 1 byte. • molti controlli di limite per evitare l’overflow ma la condizione di <> nella stringa From è imprecisa e porta all’overflow • eseguite molte operazioni matematiche sui puntatori => bp!alloc!max = +∞ e bp!used!max = +∞ (bp puntatore a buf) • warning esiste anche se le condizioni di controllo sui limiti sono corrette

30. Performance • tempi di esecuzione impiegati per il controllo del codice • CODESURFER: tempo impiegato dall’applicazione per l’analisi del codice • GENERATOR: tempo per la generazione dei vincoli • TAINT: analisi di alterazione • LPSOLVE: tempi per il metodo IIS • HIERSOLVE: tempi per il metodo gerarchico • PRE-TAINT: vincoli generati prima dell’analisi di alterazione • POST-TAINT: vincoli generati dopo l’analisi di alterazione

31. sensibilità al contesto su casi reali • Testata su wuftpd-2.6.2 usando sia l’approccio con constraint inlining sia l’approccio summary constraint • Aggiungere la sensibilità al contesto non trova nuovi overrun ma fornisce migliori valori dati dal risolutore dei vincoli • Test: controllo delle variabili “affinate” • senza sensibilità al contesto: valori per 7310 variabili • summary constraint: raffinamento di 72 variabili • Il numero di variabili di vincolo è lo stesso dell’analisi senza sensibilità al contesto • il numero di vincoli può cambiare e cresce dell’ 1% • l’approccio introduce alcuni vincoli (i “riassunti”) e rimuove altri vincoli (i vincoli degli assegnamenti dei vecchi punti di chiamata) • Constraint inlining • specializza l’insieme di vincoli per ciascun punto di chiamata • aumento di 5,8 volte nel numero di vincoli • aumento di 8,7 volte nel numero di variabili di vincolo • 7310 variabili dell’analisi senza sensibilità al contesto sono specializzate in 63704 variabili basate sul contesto di chiamata • Su 63704 variabili specializzate, 7497 variabili sono molto più precise • Su 7310 variabili non specializzate, 406 sono più precise in almeno un contesto di chiamata

32. Effetto dell’analisi dei puntatori • ridurre i falsi negativi con l’uso dell’analisi dei puntatori • tool ha la capacità di gestire, in maniera arbitraria, i livelli di dereferenziamento • confronto risultati restituiti utilizzando i puntatori e i risultati ottenuti senza analisi dei puntatori: • su sendmail sono generati 251 warning a differenza dei 295 generati con l’analisi dei puntatori • tool fallisce nel generare i vincoli per alcuni statement

33. Imperfezioni • flow insensitivity produce molti falsi allarmi • Con partizionamento è possibile affrontare questo tipo di problema • operazione manuale e dispendiosa • benefici della context sensitivity sono limitati dalla flow insensitivity dell’analisi • modellando i vincoli in termini di puntatori ai buffer piuttosto che buffer stessi, possiamo perdere gli overrun, portando a falsi negativi. • algoritmi di analisi dei puntatori sono flow insensitive e context insensitive • generare vincoli in termini di buffer avrebbe portato come risultato ad un maggiore numero di vincoli e conseguentemente ad un maggiore numero di falsi allarmi

34. Bibliografia • http://en.wikipedia.org/wiki/Buffer_overrun • Analysis and verification: Buffer overrun detection using linear programming and static analysis Vinod Ganapathy, Somesh Jha, David Chandler, David Melski, David Vitek, 10th ACM conference on Computer and communications security, 2003 • The twenty most critical internet security vulnerabilities www.sans.org/top20 • L. O. Andersen. Program Analysis and Specialization for the C Programming Language. PhD thesis, DIKU, Univ. Of Copenhagen, 1994 • C. Cowan, S. Beattie, J. Johansen, and P.Wagle PointGuardTM: Protecting pointers from buffer overflow vulnerabilities. In 12th USENIX Sec. Symp., 2003 • V. Ganapathy, S. Jha, D. Chandler, D. Melski, and D. Vitek. • Buffer overrun detection using linear programming and static analysis. 2003. UW-Madison Comp. Sci. Tech. Report 1488 ftp://ftp.cs.wisc.edu/pub/tech-reports/reports/2003/tr1488.ps.Z • CPLEX Optimizer. www.cplex.com • D. Wagner, J. S. Foster, E. A. Brewer, and A. Aiken. A first step towards automated detection of buffer overrun vulnerabilities. In Network and Distributed System Security (NDSS), 2000. • Y. Xie, A. Chou, and D. Engler. ARCHER: Using symbolic, path-sensitive analysis to detect memory access errors. In 9° European Soft. Engg. Conf. and 11th ACM Symp. on Foundation of Soft. Engg. (ESEC/FSE), 2003. • CodeSurfer http://www.grammatech.com/products/codesurfer