BigInteger p = BigInteger.probablePrime(keyLength/2, new SecureRandom()); // Generiamo un numero "probabilmente" primo, p
		BigInteger q = BigInteger.probablePrime(keyLength/2, new SecureRandom()); // Generiamo un numero "probabilmente" primo, q

		// Calcoliamo n e phi
		BigInteger n = p.multiply(q);
		BigInteger phi = p.subtract(new BigInteger("1")).multiply(q.subtract(new BigInteger("1")));

		// publicKey conterra' l'esponente pubblico e,
		// scegliendo e come il primo numero primo successivo a
		// p, esso sara' anche coprimo con phi (come richiesto nell'algoritmo)
		this.publicKey = p.nextProbablePrime();
		this.privateKey = publicKey.modInverse(phi);
		this.n = n;
	}

Una precisazione sulla funzione probablePrime() e nextProbablePrime(): esse restituiscono un numero che probabilmente e’ primo, utilizzando dei test di probabilita’ probabilistici. Il margine di errore e’ molto basso: per essere precisi, la probabilita’ che un numero restituito da queste due funzioni sia composto e’ sempre minore di 2^-100 e la velocita’ dell’algoritmo lo rende preferibile ad uno deterministico nella generazione delle chiavi. Una volta generate le chiavi, si possono gia’ creare le due funzioni di base per criptare/decriptare un numero intero. Ecco il codice:

	public BigInteger encrypt(BigInteger m) {
		return m.modPow(publicKey, n); // (m^publicKey) % n
	}
	public BigInteger decrypt(BigInteger m) {
		return m.modPow(privateKey, n); // (m^privateKey) % n
	}

Dovrebbe essere abbastanza chiaro. La funzione modPow(e, n) restituisce semplicemente this ^ e % n e ci risparmia un po di calcoli. Con queste due semplici funzioni possiamo pero’ criptare unicamente numeri interi; per poter usare l’algoritmo su un testo piu’ o meno lungo dobbiamo creare altre due funzioni che processano il testo in maniera tale da essere compatibile con l’algoritmo, i passi principali saranno questi:

1. aggiungere del padding (casuale) al testo in modo da renderlo divisibile in blocchi di uguali dimensioni. la dimensione di ogni blocco sara’ la lunghezza della chiave.
2. processare ogni blocco, convertire il testo in un intero e cifrarlo

Per il processo inverso, invece:

1. dividere il testo nel numero di blocchi in base alla chiave.
2. decriptare ogni blocco e convertire gli interi nel testo corrispondente
3. rimuovere il padding.

Ecco il codice con alcuni commenti esplicativi:

	public String encrypt(String m) {
		/* Per comodita' (piu' sotto si vedra' perche') convertiamo i
		 * caratteri del messaggio nel loro codice ASCII (esadecimale)
		 */
		String mHex = "";
		for (int i = 0; i < m.length(); i++) {
			mHex += Integer.toHexString(m.charAt(i));
		}

		/* Calcoliamo quanto padding e' necessario, chiamiamolo N, e poi concateniamo al messaggio
		 * N-1 bytes di padding casuale. L'ultimo non deve essere casuale ma deve contenere appunto
		 * il numero N, cosi' da poter poi rimuovere la giusta quantita di padding nella funzione decrypt().
		 */
		int padding = blockSize - (mHex.length()/2)%blockSize;
		for (int i = 0; i < padding-1; i++) { // Prima generiamo N-1 byte casuali
			int randomPadding = (int)(10*Math.random());
			mHex += randomPadding < 10 ? "0" + Integer.toHexString(randomPadding) : Integer.toHexString(randomPadding);
		}
		// Ultimo byte di padding
		mHex += padding < 10 ? "0" + Integer.toHexString(padding) : Integer.toHexString(padding);

		int numBlocks = (mHex.length()/2)/blockSize; // Numero di blocchi in cui dividere il messaggio

		String result = "", currentBlock = "";
		for (int b = 0; b < numBlocks; b++) {
			currentBlock = mHex.substring(b*blockSize*2, (b+1)*blockSize*2);

			/* Il blocco corrente, essendo una stringa in formato esadecimale,
			 * quindi un numero, puo' essere criptato con le due funzioni che abbiamo gia'
			 * creato precedentemente che accettano come argomento un BigInteger.
			 */
			// Questo costruttore accetta una stringa, e la base come secondo argomento
			BigInteger r = encrypt(new BigInteger(currentBlock, 16)); 

			/* Puo' accadere che la string che otteniamo come risultato abbia un byte in meno,
			 * in questo caso, per non avere problemi nel decriptare il messaggio, aggiungiamo
			 * uno zero iniziale che non cambia niente, ma la rende della dimensione corretta.
			 */
			if (r.toString(16).length() == blockSize*4) {
				result += r.toString(16);
			} else {
				result += ("0" + r.toString(16));
			}
		}
		return result;
	}

	public String decrypt(String m) {
		int numBlocks = (m.length()/2)/(blockSize*2);

		String temp = "", currentBlock = "";
		/* Questo ciclo, quasi uguale a quello della funzione encrypt(), scorre ogni
		 * blocco, lo decripta e concatena il risultato in una nuova stringa.
		 */
		for (int b = 0; b < numBlocks; b++) {
			currentBlock = m.substring(b*blockSize*4, (b+1)*blockSize*4);
			BigInteger r = decrypt(new BigInteger(currentBlock, 16));
			temp += r.toString(16);
		}

		/* Il padding e' uguale all'ultimo byte della
		 * stringa, come avevamo precedentemente impostato.
		 */
		int padding = Integer.parseInt(temp.substring(temp.length()-2), 16);
		int actualLength = temp.length() - padding*2;

		// Rimuove il padding
		temp = temp.substring(0, actualLength);

		String result = "";
		// Riconverte la stringa da esadecimale a testo
		for (int i = 0; i < temp.length(); i+=2) {
			result += (char)Integer.parseInt(temp.substring(i,i+2), 16);
		}
		return result;
	}

Tutto il codice e’ contenuto in questo archivio disponibile per il download.

L’idea di base della crittografia a chiave pubblica serve proprio a porre fine a questo inconveniente e a rendere non piu’ necessaria una comunicazione preliminare (e sicura) tra le parti per scambiarsi una chiave. In un algoritmo a chiave asimmetrica vengono infatti create due chiavi anziche’ una: quella pubblica verra’ usata da chi vuole cifrare un messaggio da inviare al possessore di quella chiave, quella privata verra’ utilizzata dallo stesso per decifrare il messaggio ricevuto. La chiave pubblica di ognuno viene, insomma, resa disponibile a chiunque voglia inviargli un messaggio, che sara’ poi decifrabile solamente usando la chiave privata, tenuta segreta.

Chiaramente le due chiavi devono essere correlate in qualche modo per avere la proprieta’ sopra descritta, e cioe’ che si possa crittografare un testo con una chiave (quella pubblica) e decriptarlo con un’altra (quella privata) ottenendo lo stesso testo di partenza. In particolare, esistendo questa relazione tra le chiavi bisogna evitare che dalla chiave pubblica, che tutti possono leggere, si possa risalire a quella privata. Bisogna cioe’ trovare un modo per generarla che sia facile da percorrere in un verso (cioe’ generare la chiave), ma che sia quasi impossibile da percorrere nell’altro, cioe’ trovare i dati usati per generarla partendo dalla chiave pubblica (altrimenti, una volta ottenuti i dati, si potrebbe generare la chiave privata ad essa associata).

I primi ad inventare un tale sistema furono W. Diffie e M. Hellman nel 1976, ma fu nel ‘77 che Rivest, Shamir e Adleman, tutti studenti del MIT, realizzarono uno degli algoritmi a chiave pubblica piu’ utilizzato al giorno d’oggi e che prende il nome di RSA. La sicurezza dell’algoritmo RSA si basa sulla difficolta’ di fattorizzare in tempi accettabili il prodotto di due grandi numeri primi: infatti, mentre e’ facilissimo calcolare il prodotto di questi due numeri, non esiste un algoritmo che possa fattorizzarlo velocemente. Nel resto di questo articolo vedremo a grandi linee come opera l’algoritmo RSA mentre nella seconda parte vedremo un’implementazione in Java.

In linea generale possiamo distinguere tre “fasi” dell’algoritmo: generazione delle chiavi, criptaggio, decriptaggio (si, lo so che suonano malissimo).

Generazione delle chiavi

1. Si generano due grandi numeri primi p, q tali che il loro prodotto n = pq ha la lunghezza in bit che desideriamo.
2. Si calcola n = pq, e phi = (p-1)(q-1)
3. Si sceglie un intero positvo e < phi e coprimo con phi (cioe’ MCD(e, phi) = 1)
4. Si calcola un intero positivo d < phi tale che ed ≡ 1 (mod phi)
5. La coppia (n, e) forma la chiave pubblica, la coppia (n, d) quella privata.

Criptaggio
Per criptare un messaggio si ottiene la chiave pubblica del destinatario e, dopo aver trasformato il messaggio di testo in un numero intero, si utilizza la formula c = m^e mod n, dove m e’ il messaggio.

Decriptaggio
Partendo dal testo criptato si usa la formula m = c^d mod n, dove c e’ il testo cifrato.

L’unico modo per decriptare un messaggio, come e’ evidente dall’algoritmo, e’ quello di essere a conoscenza dell’esponente segreto d e del modulo, n. Mentre l’esponente e’ segreto, il modulo e’ pubblico poiche’ e’ utilizzato anche per criptare il messaggio: ad ogni modo, per risalire a d, che permetterebbe di accedere al contenuto del messaggio, abbiamo bisogno non di n, ma di p e q, i due grandi numeri primi usati per generarlo. Se i numeri primi sono abbastanza grandi, e’ impossibile fattorizzare n in tempi accettabili con gli algoritmi attuali.

In questo articolo non abbiamo visto una prova teorica del funzionamento dell’RSA e cioe’ una prova del fatto che criptando un messaggio con la chiave pubblica e decriptandolo con la chiave privata si ottiene sempre di nuovo il messaggio in chiaro, ma potete trovare una dimostrazione (in inglese) a questo link: http://www.di-mgt.com.au/rsa_theory.pdf. Per comprenderla sono necessarie nozioni (non troppo avanzate) di teoria dei numeri.

Per Phil Carmody l’idea che del codice sorgente potesse essere intrinsecamente illegale era assolutamente bizarra, e cosi’ si mise a cercare un modo di rappresentare il codice di DeCSS che non potesse essere in alcun modo considerato illegale. Il sito che attualmente si trova a questo indirizzo archiviava, e archivia ancora, i numeri primi che hanno particolari proprieta’. Cosi’, armatosi di molta pazienza e di vari tool per lavorare sui numeri primi (come test di primalita’ probabilistici o deterministici), riusci’ a trovare un numero primo abbastanza lungo (1901 cifre) da meritare di essere archiviato sul sito, anche perche’ rientrava nella top 20 dei numeri primi testati con l’algoritmo ECPP. Tra l’altro, visto che gzip ignora i caratteri dopo uno zero binario alla fine di un file compresso, dovrebbero in realta’ esistere infiniti numeri primi che rappresentano la stessa cosa, cioe’ il codice compresso di DeCSS.

Dopo qualche mese, Phil Carmody e’ anche riuscito a trovare un numero primo che rappresenta un eseguibile valido in ambiente Linux e che offre le stesse funzionalita di DeCSS. Se volete qualche dettaglio piu’ tecnico sulla ricerca di questi due numeri primi potete visitare questa e questa pagina. Se non vi fidate sul fatto che quel numero primo corrisponda esattamente ad un archivio che genera il codice di DeCSS vi lascio questo programma in Perl (non scritto da me, ma opera di un certo Jamie McCarthy) che prende il numero primo da una pagina web, crea un archivio gzip ed estrae il codice:

#!/usr/bin/perl
use LWP::Simple;
use Math::BigInt;
my $html = get("http://www.utm.edu/research/primes/curios/48565...29443.html");
my($prime) = $html =~ m{<blockquote>([^<]+)</blockquote>};
$prime =~ s{\D+}{};
$prime = Math::BigInt->;new($prime);
my $binary = '';
while ($prime > 0) {
$binary = pack("N", ($prime % 2**32)) . $binary;
$prime /= 2**32;
}
$binary =~ s{^\0+}{};
open(my $fh, "| gunzip -c 2>/dev/null") or die "cannot gunzip, $!";
print $fh $binary;
close $fh;

Sulla pagina inglese di Wikipedia dedicata ai numeri primi illegali trovate anche i due numeri (quello del file gzip e quello del file eseguibile) che ho omesso in questo articolo. Alla prossima.

Quello che vedete ora nell’editor e’ il codice di base per un robot molto semplice che non fa altro che muoversi avanti e indietro e girare il suo cannone di 360 gradi, sparando quando vede un nemico. Ma analizziamo piu’ da vicino il codice:

public class MURobot extends Robot {

Creiamo una classe che eredita tutti gli attributi e i metodi dalla classe di base Robot.

	/* Qui possiamo dichiarare tutte le variabili utilizzate dal nostro robot,
	 * in questo caso non ne abbiamo.
	 */
	public void run() {
		while(true) {
			ahead(100);
			turnGunRight(360);
			back(100);
			turnGunRight(360);
		}
	}

Dopo aver dichiarato le eventuali variabili utilizzate all’interno della classe, vediamo il metodo run(). Questo metodo viene chiamato ogni qualvolta inizia la battaglia. All’interno di run() si trova quasi sempre un ciclo infinito: se l’esecuzione di run() termina, infatti, il nostro robot non fara’ altro che stare fermo e sparare ai robot che rientrano nel suo campo visivo. Se dobbiamo svolgere delle azioni particolari, come il posizionamento in una particolare zona della mappa, conviene inserirle prima di entrare nel ciclo infinito.
All’interno del ciclo il robot si muove in avanti (ahead(100)) fa un giro completo del cannone, torna indietro, fa lo stesso giro e cosi’ finche’ non viene distrutto o distrugge tutti i robot nell’arena.

	public void onScannedRobot(ScannedRobotEvent e) {
		fire(1);
	}

	public void onHitByBullet(HitByBulletEvent e) {
		turnLeft(90 - e.getBearing());
	}
}

L’ultimo metodo viene chiamato quando il nostro robot viene colpito da un proiettile: per evitare di essere colpiti di nuovo il robot si gira nella direzione perpendicolare al proiettile e quindi si sposta grazie alle istruzioni all’interno del metodo run(). Il metodo getBearing() restituisce l’angolo tra la direzione in cui ci stiamo muovendo e la direzione del proiettile ed e’ sempre compreso tra -180 e 180, ed e’ uno dei tanti metodi di cui vi parlavo in precedenza.

Se provate a iniziare una battaglia tra questo robot e altri leggermente piu’ avanzati presenti gia’ di default, vi accorgerete che le sue prestazioni non sono proprio ottimali, di fatto perdera’ la maggior parte delle battaglie se non tutte (ovviamente dipende contro chi lo fate combattere), ma e’ comunque un inizio. Il metodo migliore per realizzare robot sempre piu’ avanzati e’ cominciare da subito a crearne: ricordate anche che avendo abbastanza padronanza con Java non ci sono limiti a quello che si puo’ realizzare!

Sebbene le matrici di convoluzione, chiamate anche “kernel“, possano essere di qualsiasi dimensione, le piu’ usate sono quelle 5×5 e 3x3. In questo articolo prenderemo in considerazione solo le seconde, che sono sufficienti a creare una grande varieta’ di effetti. La matrice va applicata separatamente ad ogni canale dell’immagine (R, G, B) nel seguente modo. Supponiamo di operare esclusivamente sul canale R, visto che le operazioni sono analoghe agli altri canali, e di avere pixel con i valori indicati nella matrice a sinistra a cui vogliamo applicare la matrice di convoluzione presente a destra:

Il pixel evidenziato in rosso e’ quello su cui stiamo lavorando in questo momento, mentre la matrice a destra e’ il nostro kernel. Per applicare il filtro di convoluzione sul pixel dobbiamo immaginare di sovrapporre l’elemento centrale della matrice kernel con il pixel che stiamo considerando e di fare la somma di tutti i prodotti degli elementi sovrapposti. In poche parole dobbiamo moltiplicare gli elementi corrispondenti tra le due matrici e sommare tutti i risultati. Notate che non stiamo effettuando una normale moltiplicazione tra matrici (cioe’ un prodotto riga per colonna)!

Nel nostro caso il calcolo e’:

255*0 + 180*0 + 100*0 + 125*0 + 175*1 + 150*0 + 0*0 + 123*0 + 20*0 == 175

La matrice di convoluzione che abbiamo scelto, potrebbe essere paragonata alla matrice identita’ nel caso di un prodotto tra matrici. Come la matrice identita’ non cambia il risultato, cosi’ questa matrice  fornisce come risultato lo stesso pixel e quindi l’immagine di output rimane invariata. Ovviamente questo e’ un caso particolare, e alla fine dell’articolo vedremo alcuni degli effetti prodotti da altre matrici particolari.

Comunque, quando la matrice di convoluzione viene applicata a tutti i pixel dell’immagine il lavoro e’ terminato ed abbiamo ottenuto la nostra immagine modificata. Vediamo alcune parti del codice in C++ che trovate allegato alla fine dell’articolo. Ah, il codice fa uso, come al solito, delle librerie EasyBMP per la gestione delle BMP.

int mat[DIM][DIM];

typedef struct pixel {
	int red, green, blue;
};

Creiamo una matrice DIMxDIM (dove DIM = 3 nel nostro caso), che sara’ la nostra matrice di convoluzione, e creiamo un nostro tipo per descrivere i pixels. Dopo aver fatto inserire all’utente i 9 valori degli elementi della matrice, possiamo iniziare i calcoli. Nelle righe 38-56 (non le scrivo qua perche’ vengono formattate male) svolgiamo i calcoli veri e propri. Gli indici i e j sono le coordinate x e y del pixel che stiamo esaminando; notate che escludiamo i pixel appartenenti al bordo esterno dell’immagine semplicemente perche’ non hanno 8 pixel confinanti come tutti gli altri, e quindi verrebbe piu’ difficile applicare la matrice perche’ dovremmo escludere alcuni pixel dal conteggio; il risultato non cambia di molto.

I nuovi valori dei pixel vengono salvati in un array di oggetti pixel (il typedef che abbiamo definito poco piu’ su). Quello che ci manca è riportare questi valori in un intervallo 0…255. Sappiamo infatti che 255 e’ il valore massimo per ogni componente di un pixel, ma dall’applicazione del nostro filtro, potremmo avere (e’ spesso e’ cosi’) valori che superano questa soglia. Per fare cio’ calcoliamo la somma di tutti gli elementi della matrice di convoluzione e dividiamo tutti i valori di output per questa somma. Se dopo questa operazione ci saranno ulteriori valori > 255, li imposteremo uguali a 255, cosi’ come imposteremo a 0 quelli < 0.

Vediamo un esempio:

MATRICE DI CONVOLUZIONE 0 -1  0 -1  4  -1 0  -1  0

In questo esempio, e’ stata applicata all’immagine una matrice per individuare i bordi (edge detection). Le immagini sono piuttosto pesanti essendo BMP e quindi non compresse.

Su Internet si trovano facilmente altre matrici di convoluzione associate a risultati particolari. Ecco il codice del programma. Alla prossima.

]]> http://mindunpacked.com/2009/matrici-e-filtri-di-convoluzione/feed/ 0 http://mindunpacked.com/2009/buffer-overflow-windows/ http://mindunpacked.com/2009/buffer-overflow-windows/#comments Fri, 09 Jan 2009 14:16:01 +0000 Marco http://mindunpacked.com/?p=352 Nella parte introduttiva sull’overflow mi sembra di aver spiegato abbastanza chiaramente i fondamenti di questo tipo di errore, quasi un incubo per i programmatori. In questo articolo vedremo come sfruttare la suddetta vulnerabilità in ambiente Windows.

Il primo overflow

Passo subito alla pratica, proprio perché nel precedente articolo ho già trattato la parte teorica. Vediamo quindi un semplice programma vulnerabile all’overflow dello stack:

#include
int main(int argc, char **argv) {
char buf[20];  //inizializzo un buffer di 20 bytes
FILE* f=NULL;
int i=0;
printf("\nTest BOF");
f=fopen("input.txt","rb"); //apro il file...

while(!feof(f)) { //...e comincio a leggerne il contenuto
buf[i]=fgetc(f); //salvo i byte nel buffer
i++;
}
fclose(f); //chiudo il file
}

Si tratta di un esempio tipico di buffer overflow, dovuto all’uso incauto di un buffer nella lettura da file. Se infatti il file contiene dati per più di 20 bytes il programma andrà in crash, visualizzando il classico avviso di Windows.

Il codice, infatti, non fa altro che leggere un carattere alla volta dal file input.txt fino alla fine per poi copiarlo nella variabile buf. Naturalmente, poiché non c’è nessun controllo sulla dimensione del file, basta superare il limite del buffer per provocare la condizione di overflow. Nell’esempio, per far crashare il programma, ho inserito di proposito una stringa di 28 bytes (AAAABBBBCCCCDDDDEEEEFFFFGGGG) dove “FFFFGGGG” sono i byte eccedenti. Ma dove finiscono questi dati? Come detto la scorsa volta i dati che causano il traboccamento del buffer vanno a sovrascrivere lo stack della memoria. In questo caso, se si usa un debugger per visionare lo stato della memoria al momento dell’overflow, si noterà che il registro EIP ha assunto il valore 0×47474747 e quello EBP il valore 0×46464646, che rispettivamente equivalgono – in esadecimale – ai caratteri GGGG e FFFF.

Primi passi verso l’exploit

Modificare il registro EIP significa, in parole povere, riuscire a modificare l’esecuzione del programma, dirigendolo in una qualsiasi zona a nostro piacere. Una volta chiarito questo punto possiamo iniziare a progettare un exploit in grado di sfruttare l’overflow individuato per prendere il controllo del programma. Si procede studiando l’esecuzione del programma fino alla condizione di overflow, passo dopo passo, grazie ad un debugger. Vediamo ora la prima parte del programma. Dovete comunque tenere conto che se disassemblate un eseguibile da voi compilato l’output potrebbe differire dal mio, ciò è dovuto dalla differenza del compilatore, od anche da una versione diversa dello stesso:

00401000 push ebp //salva EBP nello stack
00401001 mov ebp,esp
00401003 sub esp,1Ch //riserva spazio per buffer
00401006 mov dword ptr [ebp-18h],0 //variabile FILE* f
0040100D mov dword ptr [ebp-1Ch],0 //variabile int i

Questa parte iniziale di codice viene generata dal compilatore e si “preoccupa” di riservare spazio nello stack utile per allocare buf (0×1C byte) e le altre variabili. Sono riportati i valori dei registri dello stack ESP e EPB prima e dopo l’esecuzione delle istruzioni. Successivamente il programma esegue la stampa a video con printf() della stringa “Test BOF”. In linguaggio assembly i prametri di una funzione vengono passati mediante salvataggio nello stack: prima della chiamata a printf() troviamo infatti un’istruzione PUSH che memorizza nello stack l’offset della stringa di testo.

00401014 push 407030h //offset stringa  “\nTest”
00401019 call 00401114 //printf()
0040101E add esp,4
...

Analizziamo ora il ciclo while che legge fino alla fine del file i byte memorizzandoli nella variabile buf:

00401033 mov dword ptr [ebp-18h], eax
00401036 mov eax, dword ptr [ebp-18h]
00401039 mov eax, dword ptr [eax-0Ch]
0040103C and ecx,10h
0040103F test ecx,ecx //test di fine file (EOF)
00401041 jne 00401061
00401043 mov edx, dword ptr [ebp-18h]
00401046 push edx
00401047 call 004010C7 //lettura da file fgetc()
0040104C add esp,4
0040104F mov ecx, dword ptr [ebp-1Ch]
00401052 mov byte ptr [ebp+ecx-14h],al //memorizza il byte in buf
00401056 mov edx, dword ptr [ebp-1Ch]
00401059 add edx,1 //incremento variabile i (i++)
0040105C mov dword ptr [ebp-1Ch],edx
0040105F jmp 00401036

l’istruzione alla riga 12 è quella che scrive nel buffer il dato letto da file mediante fget(). L’indirizzo del buffer è dato da [EBP+ECX-14h]; il valore vinere incrementato ad ogni iterazione grazie al registro ECX. E’ tuttavia la parte finale del programma, quella che segue immediatamente all’istruzione fclose(), la più interessante: viene ripristinato il valore del registro EBP e per chiudere la procedura si esegue un’istruzione di ritorno RET. Tale istruzione ha l’effetto di estrarre una word (32 bit) dallo stack e di memorizzare in eip, modificando l’indirizzo dell’istruzione corrente e spostando così il flusso di esecuzione del programma. E’ in questo momento che emergono i problemi dell’overflow e il programma raggiunge una condizione indefinita. Il ciclo while infatti, non si accorge di scrivere nel buffer più dati di quelli previsti (28 contro 20) e di conseguenza inizia a scrivere sopra lo stack alterando i valori in esso memorizzati.

00401061 mov eax, dword ptr [ebp-18h]
00401064 push eax
00401065 call 00401071
0040106A add esp,4
0040106D mov esp,ebp
0040106F pop ebp //ripristina EBP
00401070 ret //istruzione di ritorno

Tutto ciò si traduce con un errore che scatta nel momento in cui si eseguono le istruzioni POP e RET: i valori estratti dallo stack non sono quelli corretti, ma sono diventati parte dei dati letti da input; infatti, nel momento in cui si verifica il crash, ci si accorge che i registri EBP e EIP contengono i valori 0×46464646 e 0×47474747, che corrispondono proprio ai caratteri in eccedenza nel file input.txt (rispettivamente le stringe “FFFF” e “GGGG”).
Vediamo ora com’è possibile creare un exploit capace di sfruttare l’overflow del programma di esempio. Si è visto come sia possibile controllare l’andamento del programma fornendo input in eccedenza, ma è possibile andare oltre: se nell’input invece di fornire stringhe di testo, memorizziamo istruzioni assembly a nostro piacimento, possiamo iniettare il nostro codice direttamente nello stack affidato al programma e quindi modificare l’andamento del flusso d’esecuzione, dirottando il registro EIP nel punto in cui si trova il codice iniettato. L’unica difficoltà di questa fase è il calcolo degli indirizzi e degli offset di allineamento, che dovranno combaciare perfettamente per far sì che il programma ad un certo punto esegua le nostre istruzioni; analizzando la stringa di overflow ci si accorge che il valore GGGG pilota il registro EIP. La struttura dell’exploit prevede, quindi, un input di questa forma: in testa possiamo sfruttare i primi 20 byte del buffer per memorizzare il codice che vogliamo far eseguire, aiutandoci con eventuali istruzioni NOP (istruzione assembly che corrisponde a no-operation, quindi ininfluente) per allineare il codice esattamente alla dimensione di 20 byte. Seguono due word da 32 bit che corrispondono ai valori scritti dall’overflow nei registri EBP e EIP; infine, poiché per questo exploit ho pensto di visualizzare una semplice stringa di testo, memorizzeremo nella parte finale dell’input quest’ultima, terminata da 0.

Il registro EIP servirà per dirottare il flusso del programma verso l’inizio del codice da noi iniettato. Analizzando col debugger l’esecuzione del programma, si nota che il valore di EBP prima dell’overflow è 0×0012FF80, mentre lo stack usato per memorizzare i dati inizia all’offset 0×0012FF6C, che sarà proprio il punto in cui partirà il codice iniettato. Conosciamo quindi i valori delle word di EBP e di EIP, non resta che scrivere il codice da ineittare.
Come ho accennato prima, descriverò un exploit di esempio che non frà altro che stampare a schermo una stringa di testo. E’ ovvio che ci si può spingere oltre e creare i cosiddetti shellcode, ovvero del codice assembly in grado di aprire una shell sul sistema vittima, solitamente con privilegi da amministratore. Alla fine di questo articolo accennerò alla costruzione di uno shellcode, ma un argomento del genere andrebbe approfondito non poco, e richiederebbe un articolo a parte.

Ritornando all’exploit, per stampare del testo abbiamo bisogno di conoscere l’offset in cui risiede la stringa e l’indirizzo di printf(), che come si è visto prima, è localizzata a 0×00401114. Il codice assembly da iniettare sarà il seguente, per un totale di 3+5+5=13 byte.

OPCODES	ISTRUZIONE
83 EC 20	SUB ESP, 0×20
68 x1 x2 x3 x4	PUSH offset(stringa)
E8 y1 y2 y3 y4	CALL printf()

Per raggiungere i 20 bytes richiesti dall’overflow, si aggiungono 7 istruzioni NOP alla fine del codice. Gli opcodes sono i codici esadecimali che corrispondono univocamente alle istruzioni assembly; ad esempio 83 EC identifica l’istruzione SUB ESP, che seguita dal valore 0×20, sottrae 20 byte dal registro EBP. Non rimane che calcolare i valori “x1 x2 x3 x4” e “y1 y2 y3 y4” della PUSH e della CALL. L’offset della stringa di testo si calcola partendo dall’indirizzo iniziale del nostro buffer (dove inizia il codice, 0×0012FF6C) a cui si aggiungono i 28 byte del buffer, ottenendo 0×0012FF88. Per calcolare il valore di y1 y2 y3 y4 occorre invece partire dall’indirizzo della funzione printf() 0×00401114 a cui bisogna sottrarre l’offset in cui si trova l’istruzione CALL, che è dato da 0×0012FF6C+3+5+5 = 0×0012FF79. Quindi otteniamo il valore di 0×002D119B. In definitiva:

Va specificato che gli indirizzi e gli offset delle istruzioni assembly vanno scritti al contrario, cioè leggendoli da destra verso sinistra. Per creare un file di input di fatto in questo modo basta ricorrere ad un semplice programma in c++ che unisca vari pezzi dell’exploit scrivendoli su di un unico file “input.txt”. Usando il file così generato come input per il programma mostrato ad inizio articolo, l’exploit prenderà il controllo del programma visualizzando la stringa “Exploit works”. In ogni caso, al termine della funzione printf() il programma si trova in un punto indefinito, e quindi andrà in crash comunque. Ciò si può evitare aggiungendo una chiamata ad una funzione come exit().

Windows Shellcoding

Non approfondirò questo argomento, sarebbe troppo lungo e andrebbe aldilà dello scopo di questi articoli. Scrivere degli shellcode è complesso, e non cambia solo da sistema a sistema ma addirittura a seconda delle diverse versioni dello stesso. In generale uno shellcode dovrebbe aprire una shell sul sistema vittima, ma può essere usato per richiamare qualsiasi funzione di sistema approfittando dei privilegi del programma vulnerabile al buffer overflow. La difficoltà di scrivere shellcode universali è appunto dovuto al fatto che gli indirizzi delle varie funzioni cambiano a seconda del sistema. In windows è possibile risalire a tali indirizzi con un comodo programma di nome arwin. Esso permette di estrapolare l’indirizzo di una funzione presente in una determinata libreria di sistema (DLL).

C:\>arwin kernel32.dll GetProcAddressarwin
- win32 address resolution program – by steve hanna – v.01
GetProcAddress is located at 0×77e7b332 in kernel32.dll

In questo caso siamo riusciti a capire l’indirizzo della funzione GetProcAddres, che fra l’altro è molto utile per risalire a qualsiasi altra API di sistema. Il codice da iniettare dovrà essere scritto usando gli indirizzi così ricavati, avrete quindi capito che con uno shellcode si può fare qualsiasi cosa, capacità di programmazione assembly permettendo.

Le reti neurali hanno diverse applicazioni e spaziano in diversi campi. In questo paragrafo elencherò alcune applicazioni interessanti che ho trovato sulla rete e poi mostrerò come è possibile creare un molto rudimentale sistema di riconoscimento dii immagini, capace di riconoscere i numeri da 0 a 9.

Alcune applicazioni sono:

Vita artificiale: la vita artificiale tenta di simulare l’evoluzione di organismi viventi tramite computer. Spesso gli organismi sono dotati di reti neurali per svolgere i loro compiti come trovare fonti di cibo, muoversi, etc…

Finanza: prevedere l’andamento dei mercati.

Riconoscimento di forme, immagini, facce, etc…

Quello che noi creeremo è un sistema molto rudimentale di riconoscimento delle immagini, di fatto potra riconoscere solo quelle immagini che gli abbiamo presentato nel training set e non sarà probabilmente in grado di riconoscerle se gli è stato modificato anche solamente qualche pixel. E’ solo un esempio di base per mostrare cosa si può fare, ed anche in maniera abbastanza semplice. Le immagini che la nostra rete neurale sarà capace di riconoscere avranno dimensioni fisse (5×7 pixels) e saranno simili a questa:

Immagine di esempio

I quadratini con il bordo nero sono semplicemente i pixel dell’immagine. Avendo questa immagine 7×5 = 35 pixel in totale, la nostra rete neurale dovrà avere 35 neuroni di input, uno per ogni pixel. Per semplicità l’input potrà essere o 1 o 0, dove 1 simboleggia il colore rosso della precedente immagine e 0 lo sfondo. Così facendo si ottiene una matrice che rappresenta l’immagine, che nel caso di quella appena vista sarebbe questa:

0 0 1 0 0

0 1 1 0 0

0 0 1 0 0

0 0 1 0 0

0 0 1 0 0

0 0 1 0 0

0 1 1 1 0

Nell’allenamento della nostra rete, noi daremo un solo esempio per ogni numero, ma volendo potremmo dare più esempi diversi che rappresentano diversi modi di scrivere il numero 1 e così la nostra rete avrebbe una capacità più alta di riconoscere caratteri diversi (chiaramente l’allenamento sarà più lungo).

Per la nostra rete neurale creeremo noi il training set direttamente su un file di testo o altrimenti, essendo la rete neurale capace di riceve in input solo dei numeri, dovremmo creare un programma che data in input un’immagine crei la matrice numerica associata ad essa, ma siccome il nostro training set sarà molto piccolo le creeremo manualmente. Ogni riga dovrà contenere la rappresentazione di un numero, di conseguenza non avremo matrici nel file di input ma le righe saranno affiancate. Il file di input risulta così:

0 0 1 0 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 1 0 1 0 0 0 1 0 0

0 0 1 0 0 0 1 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 1 1 1 0

0 0 1 1 0 0 1 0 0 1 0 1 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 1 1 1 1

0 0 1 1 0 0 1 0 0 1 0 1 0 0 1 0 0 0 1 0 0 0 0 0 1 0 1 0 0 1 0 0 1 1 0

0 0 0 0 0 0 0 0 1 0 0 0 1 1 0 0 1 0 1 0 1 1 1 1 1 0 0 0 1 0 0 0 0 1 0

0 1 1 1 0 0 1 0 0 0 0 1 0 0 0 0 1 1 1 0 0 0 0 0 1 0 0 0 0 1 0 1 1 1 0

0 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 0 1 1 1 0

0 0 0 0 0 1 1 1 1 1 0 0 0 0 1 0 0 0 1 0 0 1 1 1 0 0 1 0 0 0 1 0 0 0 0

0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 0 1 1 1 0

0 1 1 1 0 1 0 0 0 1 1 0 0 0 1 0 1 1 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0

Se spezzate ogni riga in parti composte da 5 elementi riottenete la matrice che rapresenta il numero.

Il file di output avrà tante righe quante quelle del file di input e sarà il seguente:

1 0 0 0 0 0 0 0 0 0

0 1 0 0 0 0 0 0 0 0

0 0 1 0 0 0 0 0 0 0

0 0 0 1 0 0 0 0 0 0

0 0 0 0 1 0 0 0 0 0

0 0 0 0 0 1 0 0 0 0

0 0 0 0 0 0 1 0 0 0

0 0 0 0 0 0 0 1 0 0

0 0 0 0 0 0 0 0 1 0

0 0 0 0 0 0 0 0 0 1

I neuroni di output saranno 10 ed ognuno è associato ad un numero. Con il numero 0 il primo neurone emette un segnale mentre gli altri no, con il numero 1 il secondo neurone emette un segnale mentre gli altri no, etc… di conseguenza ci aspettiamo che dopo l’addestramento, quando passiamo in input, per esempio il numero 9 soltanto l’ultimo neurone si attiverà. Il codice è il seguente:

#include <iostream>
#include <fstream>
#include <sstream>
#include <vector>
#include <ctime>
#include <cmath>

using namespace std;

#include "Misc.hpp
#include "GenAlg.hpp"
#include "NeuralNet.hpp"
#include "NNController.hpp"

int main() {
NNController NC(35, 10, 1, 10);
NC.loadTrainingSet("input", "output");
NC.train();
NC.saveWeights("img.txt");
cout << "*** La rete e' allenata ***" << endl;
}

Come vedete, abbiamo creato 35 neuroni di input, 10 di output ed un livello nacosto con 10 neuroni.

LINKS

http://www.ai-junkie.com/ann/evolved/nnt1.html – Questo tutorial in Inglese sulle reti neurali è uno dei migliori che abbia mai letto, tant’è che ne ho preso spunto per scrivere questo. Vengono usati anche lì gli algoritmi genetici per aggiornare la rete e troverete delle somiglianze anche nelle classi del codice (però vi assicuro che il codice per questo tutorial l’ho scritto da zero

http://www.ai-junkie.com/ga/intro/gat1.html – Tutorial sugli algoritmi genetici, sempre in Inglese.

http://blacklight.gotdns.org/wiki/index.php/Introduzione_ai_sistemi_fuzzy_e_alle_reti_neurali – Implementazione di una rete neurale error back propagation in C, tutorial in Italiano.

http://www.aitalk.net – Forum sull’intelligenza artificiale in lingua Inglese. Contiene anche una piccola sezione in lingua Italiana.

Ho anche realizzato la stessa guida in formato PDF: trovate QUI un archivio contenente tutti i file sorgente di cui abbiamo parlato e la guida in formato PDF (un po meglio impaginata e con qualche illustrazione in piu’).
Alla prossi

L’algoritmo LSB (least significat bit) mira a nascondere un messaggio in un contenitore (immagine, file audiom file video) modificando i bit meno significativi. Nel nostro caso creeremo un programma per nascondere file di testo all’interno di immagini bitmap. Ogni pixel della nostra immagine e’ rappresentato da una terna di numeri che indicano le tre componenti RGB. Modificheremo il bit meno significativo di ogni componente di ogni pixel e lo adatteremo ai bit del nostro messaggio di testo. Il cambiamento che otteremo modificando solo il bit meno significativo sara’ al massimo di una unita’ e, di conseguenza, produrra’ immagini all’apparenza identiche, poiche’ un tale cambiamento non e’ percepibile ad occhio nudo.

Il nostro programma e’ sostanzialmente diviso in due parti: quella per nascondere il testo nell’immagine e quella per recuperarlo.

Steganografare un testo

La prima parte del programma si occupera’ di fare le seguenti operazioni:

1. Leggere il messaggio da un file di testo
2. Calcolare il numero di pixels necessari ad occultare il messaggio nell’immagine ed accertarsi che l’immagine sia abbastanza grande da poterlo fare. Salvare in forma binaria il valore di ogni componente di questi pixels.
3. Modificare i bit meno significativi per adattarli a quelli del messaggio
4. Scrivere i nuovi bit su una nuova immagine apparentemente uguale alla prima, ma contenente il testo.

Saltando il passo 1 (che spero chiunque sia capace di fare), passiamo al due:

numbits = message.size()*8;  // La stringa message contiene il messaggio letto dal file
numpixels = (numbits%3 == 0 ? numbits/3 : (int)numbits/3 + 1);
numrows = (int)numpixels/img.TellWidth() + 1;
if (numrows > img.TellHeight()) {
	cout << "Errore: il messaggio e' troppo lungo per essere contenuto in questa immagine." << endl;
	exit(0);
}
for (int i = 0; i < numrows; i++) {
	for (int j = 0; j < img.TellWidth(); j++) {
		bits.push_back(bitset<8>((int)img(j, i)->Red));
		bits.push_back(bitset<8>((int)img(j, i)->Green));
		bits.push_back(bitset<8>((int)img(j, i)->Blue));
	}
}

Il programma calcola il numero di bit e il numero di pixel necessari in base alla lunghezza del messaggio. Visto che ogni pixel puo’ nascondere 3 bit, il numero di pixel viene calcolato semplicemente dividendo il numero di bit per 3 e arrotondando per eccesso nel caso di resto. numrows contiene invece il numero di righe dell’immagine che bisogna copiare in memoria. Se il numero di righe e’ maggiore dell’altezza del’immagine il programma genera un errore poiche’ l’immagine e’ troppo piccola per contenere il messaggio. Dopo aver fatto cio’, salviamo i tutti i valori RGB dei pixel che ci servono in un array di bitset. bits e’ un vettore (classe vector delle STL) di oggetti bitset, una classe della STL creata appositamente per gestire dati in forma binaria. La notazione bitset<8>(…) crea un oggetto bitset con 8 bit che assumono il valore dell’argomento che gli si passa tra parentesi. Visto che i valori RGB di un’immagine sono compresi tra 0 e 255 8 bit sono sufficienti.

count = 0;
for (int i = 0; i < message.size(); i++) {
	bitset<8> temp = bitset<8>(message[i]);
	for (int b = 7; b >= 0; b--) {
		bits[count].set(0, temp[b]); // 0 e' l'indice del bit meno significativo; 		temp[b] e' il b-esimo bit della lettera che stiamo esaminando
		count++;
	}
}

Dopo aver salvato i valori in memoria, dobbiamo modificare il bit meno significativo di ogni elemento salvato per renderlo uguale a quello del nostro messaggio. Il codice qui sopra svolge questo compito: scorre ogni lettera del messaggio e crea un oggetto bitset contenente il valore di quella lettera in binario. Il ciclo innestato scorre tutti i bit della lettera e modifica i bit meno significativi dell’immagine in modo appropriato.

for (int i = 0; i < numrows; i++) {
	for (int j = 0; j < img.TellWidth(); j++) {
		imgout(j, i)->Red = (int)bits[count++].to_ulong();
		imgout(j, i)->Green = (int)bits[count++].to_ulong();
		imgout(j, i)->Blue = (int)bits[count++].to_ulong();
	}
}
for (int i = numrows; i < img.TellHeight(); i++) {
	for (int j = 0; j < img.TellWidth(); j++) {
		imgout(j, i)->Red = img(j, i)->Red;
		imgout(j, i)->Green = img(j, i)->Green;
		imgout(j, i)->Blue = img(j, i)->Blue;
	}
}
imgout.WriteToFile("out.bmp");

Una volta che i bit sono stati modificati in maniera corretta, dobbiamo solo riscriverli su una nuova immagine. Il primo ciclo scrive i bit contenenti il messaggio (la funzione to_ulong() converte un bitset nel suo valore decimale), mentre il secondo riscrive semplicemente i valori dei pixel che non sono stati modificati riprendendoli dall’immagine originale.

Recuperare il testo steganografato

La seconda parte del programma e’ quella che, data in input un’immagine recupera il testo contenuto in essa. Un difetto del programma e’ quello di richiedere la lunghezza del messaggio per poterlo estrarre: in realta’ si potrebbe ovviare a questo problema in maniera piuttosto semplice (dopo vedremo come) ma per ora, bisognera’ accontentarsi di andare a tentativi se non si conosce la lunghezza del messaggio completo.

La struttura di questa seconda parte ricalca quella della prima: dopo aver preso in input la lunghezza del messaggio ed aver calcolato in base ad essa il numero di pixel che sono stati modificati, il programma prende dall’immagine i valori delle componenti di questi pixel e li mette in un array di bitset. Un secondo ciclo:

for (int i = 1; i < numbits; i++) {
	temp.set(count, bits[i-1][0]);
	count--;
	if (count == -1) {
		count = 7;
		cout << (char)temp.to_ulong();
	}
}

si occupa di prendere i bit meno significativi a gruppi di 8 e di stampare il corrispondente valore alfanumerico.

Possibili miglioramenti

Il programma in questa maniera e’ piuttosto rudimentale, ecco alcuni possibili miglioramenti che potreste allenarvi a mettere in pratica:

1. Evitare di dover richiedere la lunghezza quando bisogna estrarre un messaggio. Una possibilita’ potrebbe essere quella di conservare i primi N bit meno significativi dell’immagine per salvare la lunghezza del messaggio e per estrarla al volo senza doverla richiedere all’utente. 10 bit permetterebbero, per esempio, di salvare un numero fino a 2¹⁰ = 1024.
2. Introdurre la possibilita’ di inserire una chiave. Una chiave potrebbe essere un numero intero N che indicherebbe al programma di modificare non tutti i pixel uno per uno ma di prendere 1 pixel ogni N. Questo ridurrebbe la capacita’ dell’immagine di contenere messaggi ma renderebbe piu’ difficile un’eventuale individuazione del messaggio.
3. Introdurre la possibilita’ di crittografare un messaggio prima di steganografarlo per una maggiore sicurezza.

Ecco il codice del programma: Steganografia in C++. Fa uso delle librerie EasyBMP per la gestione delle immagini presenti nell’archivio stesso.

Ciao!

In un ambiente tridimensionale abbiamo 3 piani perpendicolari tra di loro; in 4 dimensioni invece, questi piani diventano 6 e sono rappresentati appunto dalle varie coppie possibili dei 4 valori in entrata: [Z.r, Z.i], [Z.r, C.r], [Z.r, C.i], [Z.i, C.r], [Z.i, C.i], [C.r, C.i]. Questi piani sono tutti perpendicolari tra di loro e sono i piani che si riconoscono a prima vista, ma ovviamente il numero di piani su cui potremmo effettuare delle sezioni da visualizzare e’ infinito. Questo e’ il punto che ci permette di renderizzare delle vere e proprie animazioni che includono delle rotazioni del Buddhabrot. Prima di parlare di questo, pero’, vediamo quali sono le modifiche da effettuare al file sorgente che ho distribuito nel precedente articolo per renderizzare sezioni di piani diverse.

In realta’, la modifica da fare e’ una sola ed e’ questa: nella funzione escape() si trova questa parte:

zz[(int)N].r = ZOOM*(Z.r+OFFSET_X)*(WIDTH/2);
zz[(int)N].i = ZOOM*(Z.i)*(HEIGHT/2) + HEIGHT/2;

Come vedete, le coordinate che prendiamo in considerazione sono Z.r e Z.i. Basta cambiare questi valori per renderizzare un’altra sezione del frattale. Se al posto di Z.i mettiamo, per esempio, C.r, visualizzeremo l’oggetto visto dal piano [Z.r, C.r].

Vediamo ora come realizzare una rotazione del frattale. Quello che vogliamo fare e’, in poche parole, passare gradualmente dall’immagine di un piano, diciamo [Z.r, Z.i] a quella di un’altro, per esempio, [Z.i, C.r]. Per fare cio’ dobbiamo modificare sempre la formula precedente, nella seguente maniera:

zz[(int)N].r = ZOOM*(rot*Z.r+Z.i*(1-rot)+OFFSET_X)*(WIDTH/2);
zz[(int)N].i = ZOOM*(rot*Z.i+C.r*(1-rot))*(HEIGHT/2) + HEIGHT/2;

E’ apparso un nuovo coefficiente, rot. Questo, come potete immaginare, e’ un coefficiente che rappresenta, se vogliamo, l’angolo di rotazione. Per un valore di rot pari a 1, verra’ renderizzato il piano [Z.r, Z.i] poiche’ 1-rot = 0 e quindi le parti Z.i e C.r si annullano. Per rot = 0, avverra’ il contrario. Ovviamente per valori di rot che variano tra 0 e 1 otteremo immagini diverse, per esempio, visto che la rotazione complessiva e’ di 90° (da rot = 0 a rot = 1), rot=0.5 dovrebbe corrispondere ad una rotazione di 45°. Se si renderizzano varie immagini per valori di rot che aumentano progressivamente da 0 a 1, si otterra’ una vera e propria animazione del Buddhabrot rotante.

Ora, se non volete mettervi a modificare manualmente ogni volta il valore di rot, vi conviene aggiungere un paio di cicli for al codice e fare in modo che, ad ogni ciclo, il valore di rot venga modificato per renderizzare un’immagine diversa. Ecco un esempio di “rotazione”, anche se non appare affatto come tale:

Vi lascio un ultimo link alla pagina originale creata da chi ha scoperto questa tecnica (e’ in inglese): http://www.superliminal.com/fractals/bgram/ZrZiOut.htm

Introduzione

Va anticipato che uno dei linguaggi di programmazione più predisposti al buffer overflow (d’ora in poi BOF) è senza dubbio il C/C++. Infatti a differenza di altri linguaggi permette al programmatore un controllo quasi completo sulla memoria – quasi quanto un linguaggio assembly – ma non sempre fa gli opportuni controlli, a scapito dei programmatori alle prime armi. Linguaggi come il Java, ad esempio, hanno una gestione molto sofisticata della memoria, ricorrendo ad algoritmi di de-allocazione e a sistemi come il Garbage Collector, quindi i rischi di BOF sono molto rari.
Vediamo innanzi tutto cos’è il buffer. Nella sua accezione più generale un buffer è un’area di memoria contigua, con una dimensione prefissata, utilizzata per memorizzare dati omogenei. Nel linguaggio C un buffer è rappresentato dal puntatore all’indirizzo iniziale dell’area di memoria corrispondente. Alcune funzioni della libreria standard del C (strcpy(), strcat(), gets() e la famosa scanf()) operano su buffer di caratteri senza effettuare nessun controllo sulla dimensione del buffer di destinazione (bound checking): semplicemente arrestano la loro scrittura quando non hanno più caratteri disponibili. È evidente che in questi casi è abbastanza facile incorrere in un buffer overflow. Nel caso in cui il buffer mal gestito sia una variabile automatica, sia cioè allocato sullo stack, la situazione può venire sfruttata da un attaccante per sovrascrivere l’indirizzo di ritorno di una chiamata da funzione e forzare così l’esecuzione di codice malevolo, che può essere posizionato sia nel buffer stesso che in una variabile d’ambiente.
In sintesi un buffer overflow avviene quando in un programma, al tempo di esecuzione, una certa istruzione tenta di scrivere dentro ad un buffer più informazioni di quante esso ne possa contenere.

Organizzazione della memoria

È possibile suddividere la memoria allocata ad un processo in tre zone, ognuna specializzata per una determinata funzione: un’area text, un’area dati statica ed un’area dati dinamica:

• L’area text è un’area di sola lettura, collocata nella parte più bassa dello spazio di indirizzamento di un processo, in cui vengono memorizzate le istruzioni del programma ed è condivisa da tutti i processi che eseguono lo stesso codice; un tentativo di scrittura in quest’area dà origine ad un errore.

• L’area dati statica è a sua volta suddivisa in due regioni (data e bss), una per i dati inizializzati ed un’altra per i dati inizializzati; le variabili statiche trovano posto in quest’area.

• L’area dati dinamica è divisa a sua volta in due parti: lo stack e lo heap. Quest’ultima è un’area dati dinamica che viene allocata a run time attraverso le funzioni del C come malloc() e calloc(), e cresce verso gli indirizzi alti. Viene usato per gestire variabili dinamiche e puntatori. Andrò ora a descrivere un po’ più nel dettaglio lo stack.

Lo stack e sua gestione

Lo stack è quell’area di memoria che si trova sul fondo della memoria e che viene utilizzata durante le chiamate alle funzioni per salvare lo stato corrente dell’esecuzione e per passare i parametri per argomento. Viene gestito con la politica LIFO (Last In, First Out) e mediante due istruzioni fondamentali del linguaggio assembly: PUSH e POP. La prima memorizza un dato, la seconda lo estrae seguendo il modello LIFO, l’ultimo ad entrare è il primo ad uscire. La memorizzazione dei dati nello stack segue un ordine inverso, cioè parte dal fondo e man mano che le informazioni vengono memorizzate, sale verso la cima della memoria.
La gestione dello stack è affidata a due registri a 32-bit molto importanti, chiamati EBP e ESP (base pointer e stack pointer), usati – rispettivamente – per delimitare la cima e il fondo dello stack; quando si esegue una PUSH, il registro ESP viene decrementato di un numero di byte pari alla dimensione del dato memorizzato, quando si esegue una POP il registro ESP viene invece incrementato. Le variazioni di ESP e EBP possono inoltre essere fatte anche direttamente, tramite operazioni di somma e sottrazione (ADD e SUB): ad esempio l’istruzione SUB ESP,5 riserva cinque byte nello stack. Questo tipo di struttura si rivela efficiente e utile nella gestione della gestione delle chiamate di funzioni e procedure in un programma, costituendo quello che è il meccanismo della “call chain”: una funzione può infatti richiamare un’altra funzione che a sua volta può chiamarne un’altra ancora e così via. Il sistema operativo deve poter tener traccia di tutte le chiamate innestate fra loro ed essere in grado di tornare a punti prestabiliti del programma dove richiesto. Ogni chiamata ad una funzione viene tradotta in una istruzione di tipo CALL, che ha l’effetto di congelare l’esecuzione del codice fino a quel punto, passando poi il controllo alla funzione chiamata, dopo aver salvato lo stato corrente e l’indirizzo di ritorno (return address), che servirà per riportare l’esecuzione nel punto in cui si era interrotta (il registro EIP è quello che punta sempre all’istruzione corrente). Da questo meccanismo si evince una prima considerazione importante: poiché l’indirizzo di ritorno viene salvato nello stack, una eventuale corruzione di tale area dati impedirà ad un qualsiasi programma di ritornare in uno stato consistente, con conseguente crash dell’esecuzione.
Per approfondimenti riguardo allo stack si veda il seguente link: Stack on Hacknowledge

Usi malevoli del buffer overflow

Come ho detto ad inizio articolo abbiamo a che fare con un errore particolarmente grave, che permetterebbe ad un hacker di ottenere una shell (anche root in certi casi) sulla macchina vittima.
Detto sinteticamente – comunque nei prossimi articoli vedremo il tutto più nel dettaglio – è possibile far eseguire del codice macchina semplicemente sovrascrivendo l’indirizzo di ritorno e facendolo puntare ad uno shellcode. Quest’ultimo è un “programma” in grado di sfruttare un buffer overflow, e solitamente provoca l’apertura di una shell – per questo shellcode – sulla macchina vittima. Uno shellcode viene solitamente scritto tramite codici esadecimali che identificano le varie istruzioni assembly da eseguire, successivamente questo codice viene iniettato nel buffer e fatto eseguire modificando l’indirizzo di ritorno della funzione vulnerabile. I rischi di un errore del genere in alcuni casi possono essere gravissimi, ad esempio un login che va in buffer overflow se il nome utente è troppo lungo…
Ecco un’immagine che forse vi faciliterà la comprensione di quanto detto:

In ogni caso questo è un overflow dello stack – uno dei più comuni – ma ne esistono anche altri meno conosciuti, ed anche più difficili da sfruttare: heap overflow, frame pointer exception e l’adjacent memory overflow.
L’overflow dello stack rimane il più facile da sfruttare, poiché permette di maneggiare in maniera efficace i registri EBP, ESP e EIP, fondamentali per poter eseguire del codice

Ma vediamo ora com’è possibile prevenire un BOF:

• Non Executable Stack: questa è la soluzione più radicale. Modificando il kernel del sistema si può rendere il segmento che contiene i dati dello stack non-eseguibile, in modo che se accidentalmente o volutamente un programma dovesse finire in quellaa zona di memoria verrebbe generato un cosiddetto protection fault, terminando il processo.

• Random Stack Address: Per poter pilotare il flusso di esecuzione, un exploit deve disporre di indirizzi affidabili e validi da assegnare ai registri EIP e ESP. Utilizzando uno stack con modalità di indirizzamento casuale, si potrebbe complicare la vita ad un eventuale attaccante nella realizzazione di exploit a compatibilità universale, che cioè funzionino in qualsiasi sistema in cui sia presente il programma vulnerabile.

• Bound Checking: Il problema degli overflow nasce principalmente da disattenzioni da parte del programmatore e del compilatore, che non controlla in anticipo se una variabile è soggetta a “traboccare”. Comunque anche nel C/C++ sono presenti alcuni accorgimenti da rispettare, e perfino delle funzioni safe, che appunto effettuano dei controlli sull’input in modo che non superi la grandezza del buffer a cui è destinato. Di seguito degli esempi:

strcpy(buf, ptr); //insicuro
strncpy(buf, sizebuf(buf), ptr); //sicuro

oppure con il classico scanf():

char buf[10];
scanf("%s", buf); //insicuro
scanf("%10s", buf); //sicuro

Nei prossimi due articoli tratterò appunto questo tipo di buffer overflow, applicandolo ai due sistemi operativi più famosi, ovvero Windows e Linux.