Buffer overflow: differenze tra le versioni

Versione delle 14:03, 23 giu 2018

Versione delle 19:22, 23 ott 2018

Riga 5:

Quando, per errore o per malizia, vengono inviati più dati della capienza del buffer destinato a contenerli (che per errore, malizia o superficialità non è stato progettato a dovere), i dati ''extra'' vanno a sovrascrivere le variabili interne del programma, o il suo stesso [[stack]]; come conseguenza di ciò, a seconda di cosa è stato sovrascritto e con quali valori, il programma può dare risultati errati o imprevedibili, bloccarsi, o (se è un driver di sistema o lo stesso sistema operativo) bloccare il [[computer]]. Conoscendo molto bene il programma in questione, il sistema operativo e il tipo di computer su cui gira, si può precalcolare una serie di dati ''malevoli'' che inviati per provocare un buffer overflow consenta ad un malintenzionato di prendere il controllo del programma (e a volte, tramite questo, dell'intero computer).

Non tutti i programmi sono vulnerabili a questo tipo di inconveniente. Per i linguaggi di basso livello, come l’assembly, i dati sono semplici array di byte, memorizzati in registri o in memoria centrale: la corretta interpretazione di questi dati (indirizzi, interi, caratteri, istruzioni, ecc…) è affidata alle funzioni e alle istruzioni che li accedono e manipolano; utilizzando linguaggi di basso livello si ha dunque un maggiore controllo delle risorse della macchina, ma è richiesta una maggiore attenzione in fase di programmazione in modo da assicurare l’integrità dei dati (e quindi evitare fenomeni come il buffer overflow). I linguaggi di più alto livello, come il Java e il Python (e molti altri), che definiscono invece il concetto di tipo di una variabile e che definiscono un insieme di operazioni permesse a seconda delladel tipologiatipo, non soffrono di vulnerabilità come il buffer overflow, perché non consentono di memorizzare in un buffer una quantità maggiore di dati rispetto alla sua dimensione. Fra questi due estremi si trova il linguaggio C che presenta alcune delle astrazioni tipiche dei linguaggi di alto livello insieme a elementi tipici dei linguaggi di basso livello, come la possibilità di accedere e manipolare indirizzi di memoria: ciò rende il linguaggio suscettibile ad usi inappropriati della memoria; se a questo si unisce il fatto che alcune librerie di funzioni molto diffuse (in particolare per l’input e la manipolazione di stringhe come la ''gets'') non effettuano un corretto controllo della dimensione dei buffer su cui lavorano, e che il C è stato usato negli anni ’70 per scrivere il sistema operativo UNIX (e da questo sono poi derivati i sistemi come Linux) e molte delle applicazioni pensate per eseguire su di esso, ne consegue che ancora oggi è presente e circola una grande quantità di codice vulnerabile al buffer overflow.<ref name=":0">{{Cita libro|autore=William Stallings, Lawrie Brown|titolo=Computer Security - Principles and Practice|anno=2015|editore=Pearson|città=|ISBN=978-0-13-377392-7}}</ref>

Non tutti i programmi sono vulnerabili a questo tipo di inconveniente, infatti perché un dato programma sia a rischio è necessario che:

Riga 76:

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 questaquesto tipologiatipo di server.<ref>{{Cita web|url=http://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>