Buffer overflow: differenze tra le versioni

Versione delle 14:36, 4 set 2016

Versione delle 15:55, 4 set 2016

Riga 96:

In alternativa esistono tool più complessi in grado di effettuare l'analisi dinamica del programma, come "Rational Purify", un debugger di memoria realizzato da IBM in grado di individuare eventuali anomalie nella gestione della memoria durante l'esecuzione del programma (accesso a variabili non inizializzate, buffer overflows, deallocazione impropria di memoria ecc...). <ref>{{Cita web|url=http://www-01.ibm.com/software/awdtools/purify/compare.html|titolo=Rational Purify}}</ref>

=== Difese a livello di compilatore ===

Linguaggi di medio/basso livello come il C forniscono alte prestazioni proprio perché "risparmiano" su certi controlli che non vengono automaticamente gestiti a livello di linguaggio lasciando tale responsabilità al programmatore, e gettando dunque le basi a vulnerabilità come il buffer overflow in caso di mancanza dei controlli sulle dimensioni dei buffer durante gli accessi.

Una delle tecniche di difesa da queste anomalie è prevedere che sia il compilatore ad inserire le verifiche sulla dimensione di tutti i buffer nel codice compilato senza richiedere alcuna modifica al codice sorgente, ma solo al compilatore, a scapito però delle prestazioni che possono aumentare anche di più del 200%. <ref name=":1" /> Questa fu la direzione intrapresa da due differenti progetti di patching al compilatore ''gcc'' scritti da Herman ten Brugge e Greg McGary. <ref>{{Cita web|url=ftp://ftp.tuwien.ac.at/.vhost/www.gnu.org/software/gcc.old/extensions.html|titolo=Gcc old extensions}}</ref>

Approccio differente è invece quello di "StackShield", un'estensione del compilatore ''gcc'' per la protezione dallo stack smashing nei sistemi Linux; anziché inserire a tempo di compilazione i controlli per il ''bounds checking'' dei buffer, l'obiettivo di StackShield è quello di impedire la sovrascrittura dei ''return address'' memorizzandone una copia in una zona sicura non sovrascrivibile (all'inizio del segmento dati) all'inizio di ogni chiamata di funzione, copia che viene poi confrontata al termine dell'esecuzione della funzione con il valore memorizzato nello stack: se i valori non combaciano StackShield può terminare l'esecuzione del programma o tentare di proseguire ignorando l'attacco e rischiando al massimo il crash del programma. <ref>{{Cita web|url=http://www.angelfire.com/sk/stackshield/info.html|titolo=StackShield}}</ref>

Un'altra estensione del compilatore ''gcc'', "StackGuard", consente sia la rivelazione di eventuali stack buffer overflow sia la prevenzione degli stessi: la prima difesa tuttavia risulta molto più efficiente e portabile della seconda, in generale meno affidabile e sicura. La rivelazione si basa sulla scrittura nello stack frame di una ''canary'' ''word'' fra le variabili locali e il ''return address'' memorizzato e sull'assunto che non sia possibile sovrascrivere il RA senza alterare la ''canary word'', che prende quindi questo nome proprio in analogia all'uso dei [[Canarino domestico|canarini nelle miniere di carbone]] come primo sistema di allarme. Prima di restituire il controllo all'istruzione puntata dal RA, si controlla se la ''canary word'' ha subito alterazioni: eventuali modifiche vengono considerate come un potenziale tentativo di alterare il controllo dell'esecuzione del programma e quindi di attacco. La tecnica adottata da StackGuard è efficace solo se l'attaccante non è in grado di prevedere la ''canary word'', in questo caso sarebbe infatti in grado di progettare l'overflow in modo da sovrascrivere la ''canary word'' con il suo valore originale: StackGuard a questo scopo esegue la randomizzazione del ''canary''. <ref>{{Cita web|url=https://www.usenix.org/legacy/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf|titolo=StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks}}</ref>

== Note ==