Linux Buffer Overflow (il libro)

2009-10-18T17:37:00.002+02:00

Ammazza quanto tempo è passato dall'ultimo post!! Non mi sono reso conto di essere stato assorbito così totalmente dagli impegni lavorativi e di real life!

Beh nelle scorse settimane ho preso una decisione importante. Per non gettare nel gabinetto tuttò ciò che di "stabile" avevo scritto (circa 200 pagine), ho deciso di suddivere la pubblicazione del libro in diversi Moduli. Il Modulo 1 di Linux Buffer Overflow lo trovate qui http://ilmiolibro.kataweb.it/libro.asp?id=337493 (per l'acquisto dovete essere registrati ed è necessaria una carta di credito o semplicemente la postepay).

Questo sono i capitoli che tratta:

1 Concetti Base
2 Lo Stack
3 Stack Overflow: Vanilla
4 Off by One & Buffer Adiacenti
5 GOT & PLT
6 Format String Overflow
7 Address Space Layout Randomization

Il modulo 2 è in preparazione ma meglio che non dica quando ho intenzione di pubblicarlo perchè se no rischio di fare un'altra brutta figura (si lo so con il Modulo 1 sono in ritardo di quasi 10 mesi :)

Punto della situazione

2009-03-05T11:17:00.003+01:00

Eccomi qui a riscrivere dopo un mese di assenza. In realtà in questo periodo ho potuto lavorare poco al libro. Attualmente infatti ho scritto appena il 15% dei contenuti del capitolo No-Execute. Mi ero prefisso di terminarlo a fine Marzo ma credo che in questo momento nemmeno l'ipotesi fine Aprile sia auspicabile. Lo so è la terza volta che toppo (vi ricordate quando dicevo che volevo ultimarlo per natale???), però per noi consulenti è così: ieri ti grattavi le balls, oggi ti entrano delle grosse commesse tutte di un colpo che ti tolgono un sacco di tempo ma a cui non puoi certo dire di no.

A questo punto (e vorrei anche un vostro parare personale) sto seriamente pensando di pubblicare i capitoli già terminati. Nello specifico in questo periodo ho ricevuto molte e-mail o richieste di aiuto da parte di chi voleva avere qualche ragguaglio in più su come aggirare l'Address Space Layout Randomization. Leggendo i commenti del post precedente noterete che mi è stato chiesto anche in questo blog. Si tratta tuttavia solamente della punta dell'iceberg rispetto a quanti mi hanno fatto la stessa domanda. L'idea che mi bazzica in testa è quindi quella di prendere il capitolo 2 (generico sullo stack), capitolo 3 (pratico sugli stack overflow nei kernel 2.4) e capitolo 11 (pratico su ASLR nei kernel 2.6), unirli e cominciare già a pubblicarli (si tratta di circa 120 pagine). Che ne pensate?

A voi la parola...(sempre che ci sia ancora qualcuno a leggermi ;)

Capitolo su FORTIFY_SOURCE terminato: Enter No-Execute

2009-01-26T14:39:00.005+01:00

Ho appena terminato il capitolo su FORTIFY_SOURCE, una patch per GCC implementata oramai su diverse distribuzioni linux, ma utilizzata ancora da poche (Fedora e Red Hat in primis) per proteggere i pacchetti precompilati ed aggiungere un ulteriore livello di protezione contro Stack, Heap e Format String Overflow. La patch non è comunque infallibile, nel senso che vi sono dei casi (soprattutto in presenza di buffer allocati dinamicamente) che non riesce efficacemente a controllare.

Facciamo invece il punto della situazione del lavoro fin qui svolto:

- Ho scritto in tutto al momento 7 capitoli per un totale di 188 pagine nette

Nella prima parte del libro all'appello mancano ancora i seguenti argomenti:

- Come il processore gestisce i calcoli matemici (in particolare sugli interi)
- Integer Overflow
- Descrizione dell'Heap
- Heap Overflow

Nella seconda parte devo invece ancora parlare di:

- Protezione No-Execute
- Propolice
- Sfruttamento avanzato degli Heap Overflow

Penso di procedere in questo modo. Il prossimo capitolo che tratterò sarà No-Execute. Poi toglierò di mezzo gli Integer Overflow, quindi parlerò di Propolice ed alla fine farò tutta una tirata con le tematiche Heap.

Tempo stimato alla conclusione del testo: francamento non lo so. Spero per fine Febbraio ma è più probabile Marzo. Dipenderà molto dai carichi di lavoro che dovrò sopportare in queste settimane.

Un saluto.

Capitolo 13: primi passi

2009-01-11T15:56:00.003+01:00

Sono rientrato dalle festività oramai da qualche giorno e mi sono subito messo al lavoro per portare a termine il capitolo sui Format String Overflow rimasto in sospeso. Completato questo sto adesso balzando direttamente al capitolo 13 sempre collegato con la stessa tematica ma vista nell'ottica dei kernel 2.6. Nella loro metodica di sfruttamento, in alcune distro non cambia nulla a parte la necessità di indovinare il punto in cui lo shellcode verrà collocato (ostacolo che abbiamo già visto come superare nel capitolo 11 sull'ASLR). Le cose si complicano un pò invece su quelle distribuzioni o quelle architetture che supportano l'NX e diventano ancor più complesse in caso di applicazioni vulnerabile compilate con FORTIFY_SOURCE=2. Questi sono i 3 scenari che analizzerò nel capitolo. Il tutto verrà completato (spero) con un caso di vulnerabilità reale.

Format String Overflow: Completamento al 50%

2008-12-21T12:02:00.009+01:00

Sono giunto alla metà abbondante del capitolo format string overflow. E' interessante come ci siano degli usi poco noti di questa tecnica. Solitamente si tende a sovrascrivere un puntatore nel GOT o nella sezione DTORS per eseguire uno shellcode. Nelle vecchie distribuzioni potevi anche alterare la sezione PLT o il punto in cui veniva mappata la funzione _fini(). Oggi comunque entrambi quest'ultimi vengono mappati in aree eseguibili ma non modificabili (basta elencarle con readelf per accorgersene). Un qualsiasi tentativo di scrittura causerà quindi un crash dell'applicazione.

Per fortuna esistono ancora molte distribuzioni (Slackware, Debian ed Ubuntu tanto per fare qualche nome ) che permettono di copiare uno shellcode in aree scrivibili (non executable quindi) ma che una volta accedute dal GOT (o da qualsiasi altra zona "puntatore") permettono di eseguire lo shellcode. Le cose si complicano notevolmente comunque in presenza di distribuzioni con funzionalità simili ad Exec Shield (Fedora/RHEL o quelle distro hardenizzate con GrSecurity). L'exploiting diventa assai difficile ma non impossibile.

Per non parlare poi delle applicazioni compilate con FORTIFY_SOURCE. Questa è una bella bestia che rende impossibile l'utilizzo dell'operatore "%n" in zone di memoria su cui si potrebbe scrivere, ma ne parlerò magari in un altro intervento del blog.

A presto

Enter The Format String Overflow

2008-12-05T09:38:00.002+01:00

Ho completato il capitolo che ho già dettagliato nel precedente post. Adesso passerò ai format string overflow. Oggi ho anche definitivamente abbandonato l'idea di lanciare il mio libro per il periodo natalizio. Non ci arrivo. Ogni tanto mi distraggo e lavoro :P

Forse è meglio così. Il 2008 è stato un anno difficile (non parlo della crisi economica, ma proprio a livello personale). Magari il 2009 porterà più fortuna. Una considerazione poi va indubbiamente alla frequentazione di questo blog. In effetti comincio a temere di essere l'unico a leggerlo :<

Off-by-one / Off-by Few e blocchi di memoria adiacenti

2008-11-30T09:37:00.006+01:00

Ho terminato il capitolo sull'Address Space Layout Randomization da una settimana. Purtroppo impegni di lavoro mi hanno tenuto impegnato più del dovuto ed ho potuto lavorare al mio libro solo negli orari notturni in cui solitamente sono meno lucido. Non riesco più a fare come un tempo, a passare intere nottate davanti al PC...quindi fino a qualche giorno fa ho svolto principalmente un lavoro di revisione del pregresso.

Ho cominciato il capitolo sugli Off-by-one / Off-by-few da poco quindi.

In merito agli off-by-one gli scenari più importanti che sto descrivendo sono due. Il primo è quando, all'interno di una funzione, il buffer che viene sovrascritto di un byte oltre le sue reali capacità di contenimento si trova in testa alla funzione stessa. In questo caso l'overflow può alterare il byte meno significativo (che nei sistemi little-endian si trova prima in memoria) dell'indirizzo del frame della funzione chiamante salvato nello stack. Nelle distribuzioni Linux più recenti però, il compilatore gcc aggiunge del padding e dilata la distanza in memoria tra il buffer ed il frame pointer, quindi solitamente si può arrivare ad alternarne l'indirizzo con un off-by-few.

Il secondo scenario tratta i blocchi di memoria adiacenti. In alcuni casi, giocando sul comportamento di alcune funzioni libc che non terminano le stringhe con il carattere NULL (ad esempio nel caso di strncpy() se source non è minore di len) si può rendere due blocchi di memoria contigui un unico blocco. Ciò può causare problemi più avanti nel codice dell'applicazione. Non si tratta di un off-by-one nel vero senso della parola ma mi è sembrato il giusto capitolo in cui inserire questo scenario.

Capitolo su ASLR quasi terminato

2008-11-16T10:19:00.004+01:00

Tra oggi e domani penso che completerò il capitolo sull'Address Space Layout Randomization. Ho analizzato tutti gli scenari possibili ed immaginabili (RET2ESP, RET2RET, RET2EAX e RET2REG in generale). Adesso mi rimane solo da presentare la parte relativa a Return into Libc coadiuvata da un'attacco bruteforcing. Se in un sistema con ASLR osservate infatti come cambia durante l'esecuzione ripetuta di un programma lo spazio di indirizzamento dello stack e degli indirizzi libc , noterete un notevole mutamento. Ma se ad essere in esecuzione in memoria è un servizio (processo parente) che ad ogni connessione di un client genera un processo figlio per gestire la risultante richieste, bhe l'organizzazione dello stack e gli indirizzi in memoria di funzioni importanti come system() o execl() rimarranno sempre gli stessi da figlio a figlio (almeno fino a quando il parente non verrà riavviato). Ciò spalanca le porte ad un possibile scenario di brute-forcing che necessita di un numero di tentativi limitato prima di concludersi con successo. E' proprio l'ultima parte che sto trattando in questo capitolo.

Bau!

Capitolo ASLR quasi terminato

2008-11-12T15:26:00.004+01:00

Sono quasi giunto al termine del capitolo che parla dell'Address Space Layout Randomization. Mi manca un'ultima parte. Nel frattempo ho buttato su carta l'organizzazione del capitolo 4 "Off by one / Off by few". Ora che ci penso non ho mai descritto quali categorie di buffer overflow sto esaminando nel mio libro:

- Stack Overflow
- Off by one / Off by few Overflow
- Format String Overflow
- Heap Overflow
- Integer Overflow

Dicevo che prossimamente mi cimenterò nel capitolo degli off by one/off by few overflow. Qui mi trovo ad un bivio. Alcuni off by one si manifestano nello stack, altri invece nell'heap. Poiché intendo trattare gli heap overflow nei capitoli 8 (basic) e 15 (advanced), credo che dovrò dividere la trattazione sugli off by one/ off by few anche su due capitoli diversi.

Organizzazione del libro

2008-11-09T11:19:00.005+01:00

L'organizzazione del libro ce l'ho già in testa da un pò. Ho buttato una bozza dei capitoli presenti ma per adesso mi soffermerò più su linee generiche. Il book sarà suddiviso in due parti. Nella prima(composta da dieci capitoli) affronterò le basi per chi ha solo un'infarinatura di questi argomenti alternando un capitolo teorico ad uno o più pratici. Ovvero, se dovrò orientarmi sugli Heap Overflow, il capitolo prima sarà immancabilmente una trattazione su cosa è l'heap, le operazioni che vi si possono condurre, i controlli, etc.. Idem con patate per lo Stack. Se devo parlare di format string overflow, prima è doveroso capire cosa sono le sezioni GOT e PLT di un file ELF, così come prima di parlare di integer overflow vi sarà un capitolo che tratterà la parte teorica, ovvero come il sistema effettua i calcoli sugli interi e roba simile.

Immancabilmente i capitoli teorici saranno molto più brevi di quelli pratici. Ad esempio ho già terminato quelli su Stack Overflow. Il teorico (capitolo 2) è venuto 9 pagine, il pratico (capitolo 3) sono 45 pagine. Ho anche terminato il teorico su Global Offset Table e Procedure Linkage Table (capitolo 5) ed è venuto di 16 pagine.

La seconda parte del libro (per il momento altri 5 capitoli) parlerà degli argomenti più avanzati, principalmente di tutte quelle migliorie introdotte nei kernel 2.6. La prima parte si può invece considerare più orientata alle installazioni con kernel 2.4 (che sono ancora numerosissime in rete). Al momento stavo lavorando sul capitolo 11 della seconda parte del libro (Address Space Layout Randomization). Penso di essere verso la metà dell'argomento e sono già a 26 pagine.

Ovviamente gli scenari che sto trattando sono sia locali che remoti ed in ogni capitolo pratico, alla fine, sto mettendo anche casi di exploit reali, insomma non semplicemente quei programmini di esempio con strcpy() utilizzato a minchia tanto per far vedere come un buffer viene sovrascritto (non fraintendetemi, all'inizio sono importanti ma poi per far pratica bisogna pur elevarsi con casi reali).

Se 15 capitoli vi sembrano una cosa da poco considerate che il target dell'argomento è solo Linux. Inoltre questo è un libro specifico sui buffer overflow e non un calderone dispersivo su altri temi, come spesso sono invece organizzati altri testi.

Perchè un altro libro sui buffer overflow

2008-11-08T13:03:00.007+01:00

Ultimamente mi è capitata tra le mani la seconda edizione di Shellcoder's Handbook, un libro inglese edito da Wiley, che aspira a fare luce su alcune classiche tematiche hacking fra le quali i buffer overflow. Il tizio che me lo ha mostrato durante un mio intervento sulla sicurezza in un convegno a Roma organizzato da un cliente per cui lavoravo, era tutto felice e non stava più nella pelle per l'uscita di questa nuova edizione. In realtà sfogliando il testo ne sono rimasto profondamente deluso. Avendo acquistato la prima edizione nel 2004, ho notato che da allora non è stato aggiunto molto materiale (a parte qualche capitolo di rintoppo qua e là come quello sugli apparati di rete Cisco). Ad esempio, le tecniche di buffer overflow descritte sono rimaste esattamente quelle di 4 anni fa, quando ancora la pressocché assenza in quasi tutte le distribuzioni Linux di meccanismi di protezione come ASLR e Propolice (tanto per citarne un paio) permetteva di piazzare uno shellcode ovunque in memoria ed eseguirlo. Mi verrebbe da dire però a Litchfield, Koziol, Aitel e compagni che siamo già nel 2008. Oggi non puoi pensare che Exec Shield non si incazzi quando provi a fare ritornare una funzione verso un'indirizzo dello stack o che la macro unlink() sia così stupida da non fare un controllo di base per capire se l'heap è corrotto o meno. Shellcoder's Handbook seconda edizione si limita invece solamente a dare qualche consiglio e fare qualche accenno sui moderni "ostacoli". Nessuna nuova tecnica, nessun esempio pratico, nessuna sessione di debugging! Solo vaghi riferimenti sul web. Al momento inoltre non esiste, a mio parere, nella letteratura esistente, un buon testo che discuta su questi temi anche prendendo in considerazione gli ultimi meccanismi di protezione implementati dalle recenti distribuzioni Linux. E' per questo che ho deciso di iniziare a scrivere un libro sull'argomento buffer overflow. Ci sto già lavorando da circa un mese e nei prossimi giorni approfitterò di questo blog per informare sullo "stato di avanzamento lavori", sulle modalità di pubblicazione, sugli argomenti trattati ed ovviamente rimarrò sintonizzato sui commenti ed i pareri degli utenti della rete. Per i tempi di rilascio non so ancora dire nulla di certo. L'auspicio è di riuscire a pubblicarlo prima di natale.