Buffer overflow: differenze tra le versioni

Versione delle 22:11, 7 set 2016

Versione delle 10:32, 13 set 2016

Riga 6:

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 della tipologia, 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>

Questo tipo di debolezza dei programmi è noto da molto tempo, ma solo di recente la sua conoscenza si è diffusa tanto da permettere anche a dei [[Cracker (informatica)|cracker]] capaci di sfruttarla per bloccare o prendere il controllo di altri computer collegati in rete. Non tutti i programmi sono vulnerabili a questo tipo di inconveniente: perché un dato programma sia a rischio è necessario che:

#il programma preveda l'input di dati di lunghezza variabile e non nota a priori;

#li immagazzini entro [[buffer]] allocati nel suo spazio di memoria, dati vicini ad altre strutture, dati vitali per il programma stesso;

#il programmatore non abbia implementato alcun mezzo di controllo della correttezza dell'input in corso.

#l'area di memoria dello stack sia eseguibile, se si tenta di scrivere dello shellcode sullo stack; questo non è vero sui computer più recenti dotati di [[NX bit]]

La prima condizione è facilmente verificabile, dalle specifiche del programma; la seconda e la terza invece sono interne ad esso e riguardano la sua completezza in senso teorico.

== Storia ==