Buffer overflow: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Nessun oggetto della modifica |
Aggiornata sezione "Storia", mancano citazioni |
||
Riga 1:
{{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.
==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 inviata 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 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
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:
Riga 14 ⟶ 15:
== Storia ==
I buffer overflows divennero noti e furono parzialmente documentati al pubblico già nel 1972, quando il Computer Security Technology Planning Study individuò un exploit capace di sfruttare la vulnerabilità: "The code performing this function does not check the source and destination addresses properly, permitting portions of the monitor to be overlaid by the user. This can be used to inject code into the monitor that will permit the user to seize control of the machine.", dove per ''monitor'' si intendeva quello che oggi è il kernel.
Esempi di buffer overflow dovuti al data integrity model del linguaggio C furono rilevati già nel 1973, mentre il primo clamoroso esempio di attacco basato su buffer overflow fu il [[Morris worm|Morris Worm]] (noto anche come Internet Worm), che nel 1988 portò al crash di più di 6.000 sistemi connessi a Internet in poche ore, sfruttando il buffer overflow nel processo demone fingerd per propagare da macchina a macchina. <ref>{{Cita web|url=https://www.sans.org/reading-room/whitepapers/securecode/buffer-overflow-attack-mechanism-method-prevention-386|titolo=Inside the Buffer Overflow Attack:Mechanism, Method, & Prevention}}</ref>▼
▲
Nonostante sia una delle vulnerabilità note da più tempo, ancora oggi il buffer overflow rappresenta una falla di sicurezza diffusa ed estremamente attuale: organizzazioni come [[CERT|CERT/CC]] e [[SANS]] pubblicano ancora oggi avvisi relativi alla sicurezza informatica che includono un numero rilevante di exploit basati su buffer overflow; inoltre diversi elementi della lista “CWE/SANS Top 25 Most Dangerous Software Error” sono varianti del buffer overflow.<ref>{{Cita web|url=http://cwe.mitre.org/top25/|titolo=CWE -▼
2011 CWE/SANS Top 25 Most Dangerous Software Errors|sito=cwe.mitre.org|accesso=2016-08-17}}</ref>▼
Più tardi, nel 1995, Thomas Lopatic pubblicò sulla mailing list di Bugtraq un exploit basato sullo stack smashing nel web server NCSA HTTPD su sistema operativo HP-UX, e un anno dopo, nel 1996, Elias Levy (anche noto come Aleph One) pubblicò un articolo intitolato "Smashing the Stack for Fun and Profit" sull'''ezine'' Phrack, una guida step-by-step alle tecniche di exploiting degli stack buffer overflows.
In seguito i buffer overflows furono sfruttati da due importanti ''internet worms'': nel 2001 il Code Red worm, che sfruttava il buffer overflow nei server Microsoft Internet Information Services (IIS) 5.0, e nel 2003 l'SQL Slammer worm, che compromise le macchine che eseguivano Microsoft SQL Server 2000.
▲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à=|p=|pp=|ISBN=978-0-133-77392-7}}</ref>
▲Nonostante sia una delle vulnerabilità note da più tempo, ancora oggi il buffer overflow rappresenta una falla di sicurezza diffusa ed estremamente attuale: organizzazioni come [[CERT|CERT/CC]] e [[SANS]] pubblicano ancora oggi avvisi relativi alla sicurezza informatica che includono un numero rilevante di exploit basati su buffer overflow; inoltre diversi elementi della lista “CWE/SANS Top 25 Most Dangerous Software Error” sono varianti del buffer overflow.<ref>{{Cita web|url=http://cwe.mitre.org/top25/|titolo=CWE -
▲ 2011 CWE/SANS Top 25 Most Dangerous Software Errors|sito=cwe.mitre.org|accesso=2016-08-17}}</ref>
== Tipi di buffer overflow e possibili attacchi ==
| |||