Buffer overflow: differenze tra le versioni

Versione delle 04:30, 30 apr 2019

Versione delle 09:57, 17 feb 2020

Riga 1:

{{Torna a|Buffer}}

{{Nota disambigua|il buffer overflow legato alle telecomunicazioni|Buffer overflow (telecomunicazioni)}}

In [[informatica]] il '''buffer overflow''' (o '''buffer overrun''') è una condizione di errore che si verifica a [[runtime]] quando in un [[buffer]] di una data dimensione vengono scritti dati di dimensioni maggiori. Quando questo accade viene sovrascritta parte della zona di memoria immediatamente adiacente al buffer in questione, con diversi effetti possibili a seconda di dove è situato il buffer e di come è organizzata la memoria in quella particolare piattaforma software; in alcuni [[Programma (informatica)|programmi]] software questo provoca delle vulnerabilità di [[sicurezza informatica|sicurezza]]. I linguaggi '''managed''', cioè basati su un modello di memoria gestito a runtime come Java, dovrebbero in teoria essere immuni da questo tipo di errore, ma in pratica la possibilità rimane presente in caso di chiamate a codice nativo, o a causa di bug del modulo manager (la JVM nel caso di Java) o del compilatore JIT.

'''Buffer overflow''' (o '''buffer overrun'''), in [[informatica]], è una condizione di errore che si verifica a [[runtime]] quando in un [[buffer]] di una data dimensione vengono scritti dati di dimensioni maggiori.

==Descrizione==

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 del tipo, 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:

* Il programma preveda l'input di dati di dimensione variabile e li memorizzi all'interno di un buffer;

* Il linguaggio di programmazione utilizzato non preveda controlli automatici di ''bounds checking'' del buffer (a tempo di compilazione o a tempo di esecuzione), e il programmatore non inserisca tali verifiche all'interno del codice.

== Storia ==

Riga 25 ⟶ 18:

Nel febbraio 2016 i ricercatori di Google e di Red Hat scoprirono la presenza di una vulnerabilità di tipo stack buffer overflow nella funzione ''getaddrinfo'' della libreria ''[[glibc]]'' (tutte le versioni a partire dalla 2.9). Tale libreria è utilizzata da centinaia di applicazioni e dalla maggior parte delle distribuzioni Linux (incluse quelle installate nei router e in altro tipo di hardware): la funzione interessata è quella che si occupa del DNS lookup (risoluzione nomi degli host e indirizzi IP) e la vulnerabilità può permettere a un attaccante l'invio di domini o DNS server malevoli, oltre che attacchi ''[[Attacco man in the middle|man-in-the-middle]]'' fino all'esecuzione di codice arbitrario sulla macchina della vittima.<ref>{{Cita web|url=https://security.googleblog.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html|titolo=CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow|lingua=en|accesso=6 settembre 2016}}</ref><ref>{{Cita web|url=https://access.redhat.com/it/node/2171131|titolo=Falla di sicurezza critica: glibc stack-based buffer overflow in getaddrinfo() (CVE-2015-7547) - Red Hat Customer Portal|sito=access.redhat.com|accesso=6 settembre 2016}}</ref>

==Descrizione==

== Tipi di buffer overflow e possibili attacchi ==

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).

Il buffer overflow può essere indicato con diversi nomi a seconda della posizione occupata dal buffer all’interno della memoria allocata per il processo.

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 del tipo, 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:

* Il programma preveda l'input di dati di dimensione variabile e li memorizzi all'interno di un buffer;

* Il linguaggio di programmazione utilizzato non preveda controlli automatici di ''bounds checking'' del buffer (a tempo di compilazione o a tempo di esecuzione), e il programmatore non inserisca tali verifiche all'interno del codice.

== Conseguenze ==

In [[informatica]] il '''buffer overflow''' (o '''buffer overrun''') è una condizione di errore che si verifica a [[runtime]] quando in un [[buffer]] di una data dimensione vengono scritti dati di dimensioni maggiori. Quando questo accade viene sovrascritta parte della zona di memoria immediatamente adiacente al buffer in questione, con diversi effetti possibili a seconda di dove è situato il buffer e di come è organizzata la memoria in quella particolare piattaforma software; in alcuni [[Programma (informatica)|programmi]] software questo provoca delle vulnerabilità di [[sicurezza informatica|sicurezza]]. I linguaggi '''managed''', cioè basati su un modello di memoria gestito a runtime come Java, dovrebbero in teoria essere immuni da questo tipo di errore, ma in pratica la possibilità rimane presente in caso di chiamate a codice nativo, o a causa di bug del modulo manager (la JVM nel caso di Java) o del compilatore JIT.

Il buffer overflow può essere indicato con diversi nomi a seconda della posizione occupata dal buffer all’interno della memoria allocata per il processo. La posizione del buffer è importante in quanto gli effetti del buffer overflow sono principalmente legati a:

La posizione del buffer è importante in quanto gli effetti del buffer overflow sono principalmente legati a:

* cosa c’è vicino al buffer

* quali dati vanno a sovrascrivere le aree di memoria adiacenti al buffer

== Vulnerabilità ==

=== Memoria virtuale di un processo ===

Quando viene eseguito un programma il sistema operativo normalmente genera un nuovo processo e alloca in memoria centrale uno spazio di memoria virtuale riservato al processo stesso.

Riga 129 ⟶ 133:

== Voci correlate ==

{{Div col|2}}

*[[Heap overflow]]

*[[Stack overflow]]

Riga 145 ⟶ 150:

*[[Sicurezza informatica]]

*[[Computer]]

*[[Cracker (informatica)|Cracker]]

*[[NX-bit|NX bit]]

*[[Morris worm|Morris Worm]]

Riga 162 ⟶ 167:

*[[Microsoft Windows]]

*[[ASLR]]

{{Div col end}}

== Collegamenti esterni ==