Buffer overflow: differenze tra le versioni

Versione delle 19:40, 28 mag 2022

Versione delle 19:52, 28 mag 2022

Riga 79:

Un programma può richiedere al sistema operativo di allocare dinamicamente una certa quantità di memoria nell'area [[Heap (struttura dati)|heap]], sfruttando chiamate di sistema come ''malloc()'' e ''free''() in C/UNIX. Questi buffer possono ugualmente essere suscettibili a problemi di overflow nel momento in cui vi si possa inserire una quantità di dati superiore alla memoria allocata, e questi dati andrebbero come al solito a sovrascrivere le aree di memoria adiacenti al buffer.

Si parla in questi casi di '''heap overflow''', ma a differenza dello stack, nell'area heap non sono memorizzati né indirizzi di ritorno, né frame pointer che possano essere alterati da un attaccante per trasferire il controllo dell'esecuzione a codice arbitrario. Tuttavia questo non significa che tali anomalie non costituiscano delle vulnerabilità pericolose: nel 2002 fu riscontrata una vulnerabilità di tipo heap overflow in un'estensione di Microsoft IIS che poteva essere sfruttata per eseguire codice arbitrario proprio su questo tipo di server.<ref>{{Cita web|url=https://www.kb.cert.org/vuls/id/363715|titolo=Vulnerability Note VU#363715 - Microsoft Internet Information Server (IIS) vulnerable to heap overflow during processing of crafted ".htr" request by "ISM.DLL" ISAPI filter|sito=www.kb.cert.org|accesso=19 agosto 2016}}</ref>

Quando un programma presenta diverse funzioni che eseguono la stessa operazione ma in modo diverso (ad esempio il ''sorting''), e si desidera stabilire a ''runtime'' quale utilizzare per processare i dati in ingresso, spesso si usa memorizzare dei puntatori a funzione nell'area heap: questi puntatori contengono gli indirizzi iniziali delle funzioni, e vengono utilizzati per richiamarne successivamente l'esecuzione. In uno scenario del genere, un attaccante potrebbe sfruttare l'overflow di un buffer allocato sullo heap per sovrascrivere tali puntatori, sostituendoli con un puntatore allo shellcode iniettato attraverso l'overflow: la successiva chiamata a una delle funzioni comporterebbe il trasferimento del controllo allo shellcode invece che alla funzione attesa.<ref>{{Cita web|url=https://www.sans.org/reading-room/whitepapers/threats/buffer-overflows-dummies-481|titolo=Buffer Overflows for Dummies - SANS Institute}}</ref>

== Contromisure ==

Esistono varie tecniche per prevenire o rivelare il fenomeno del buffer overflow, con vari tradeoff. In generale queste difese possono essere adottate a vari livelli:<ref name=":1">{{Cita web|url=http://www.preserve-it-all.org/emc-plus/rsa-labs/historical/countermeasures-against-buffer-overflow-attacks.htm|titolo=RSA Laboratories - Countermeasures against Buffer Overflow Attacks|sito=www.preserve-it-all.org|accesso=31 agosto 2016}}</ref>

* A livello di linguaggio

* A livello di codice sorgente

Riga 93:

La miglior difesa da attacchi basati sul buffer overflow sta nella scelta di un linguaggio di programmazione che fornisca controlli automatici sulla dimensione dei buffer (o a tempo di compilazione o a ''runtime'') come Java, Python o Perl. Se questa opzione può essere presa in considerazione per lo sviluppo di nuovi programmi, resta però difficilmente applicabile nel caso di progetti esistenti, in cui ciò comporterebbe la riscrittura del codice nel nuovo linguaggio.<ref name=":1" />

Un'alternativa consiste nell'utilizzo di ''safe libraries'', ovvero librerie di funzioni che implementano protezioni contro il buffer overflow: in C rappresentano funzioni vulnerabili ''strcat'', ''strcpy'', ''gets'', ''sprintf'' (e altre ancora...) di cui esistono controparti "sicure" come ''strncpy'', ''strncat'', ''snprintf''. Un esempio di queste ''safe libraries'' sono "libsafe", "libparanoia" e "libverify".<ref>{{Cita web|url=https://www.freebsd.org/doc/en/books/developers-handbook/secure-bufferov.html|titolo=3.3. Buffer Overflows|sito=www.freebsd.org|accesso=31 agosto 2016}}</ref> Libsafe, ad esempio, implementa una tecnica di protezione dallo stack buffer overflow basata sul controllo di eventuali alterazioni dello stack quando una funzione termina di eseguire: se lo stack risulta modificato, il processo termina con un [[errore di segmentazione]].<ref>{{Cita web|url=https://directory.fsf.org/wiki/Libsafe|titolo=Libsafe - Free Software Directory|sito=directory.fsf.org|accesso=4 settembre 2016}}</ref>

=== Difese a livello di codice sorgente ===

Riga 119:

* PaX<ref>{{Cita web|url=https://pax.grsecurity.net/|titolo=Homepage of PaX|sito=pax.grsecurity.net|accesso=4 settembre 2016|urlarchivio=https://web.archive.org/web/20161027061231/http://pax.grsecurity.net/|dataarchivio=27 ottobre 2016|urlmorto=sì}}</ref>

* Exec Shield<ref>{{Cita web|url=https://lwn.net/Articles/31032/|titolo="Exec Shield", new Linux security feature [LWN.net]|sito=lwn.net|accesso=4 settembre 2016}}</ref>

* OpenWall<ref>{{Cita web|url=https://www.openwall.com/|titolo=Openwall - bringing security into open computing environments|sito=www.openwall.com|accesso=4 settembre 2016}}</ref>

Le versioni più recenti di [[Microsoft Windows]] lo supportano sotto il nome di Data Execution Prevention (DEP) (o protezione esecuzione programmi).<ref>{{Cita web|url=https://kc.mcafee.com/corporate/index?page=content&id=KB58554&locale=it_IT&viewlocale=it_IT|titolo=McAfee KnowledgeBase - Prevenzione esecuzione programmi e Protezione da overflow del buffer|sito=kc.mcafee.com|accesso=4 settembre 2016}}</ref>