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

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

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

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%

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

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

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.