Ricerca tra la vecchia roba

Compilare un kernel per il Samsung Galaxy S

Posted: Ottobre 9th, 2011 | Author: | Filed under: Guide | Tags: , , , , | Commenti disabilitati su Compilare un kernel per il Samsung Galaxy S

Prima di tutto andare sul sito della samsung che mette a disposizione i sorgenti e selezionare il sorgente più ultimo che corrisponde al file GalaxyS_OpenSource_GB_Update2.zip (in realtà dipende da che versione di kernel avete sul cellulare e non ho un mapping fra archivi e versioni, nel caso scaricateveli ed informatemi).

All’interno dei sorgenti ci dovrebbe essere un file chiamato build_kernel.sh che dovrebbe buildare il tutto ma pare non scritto perfettamente bene. Alla fine la procedura da seguire è la seguente: prima di tutto

$ make ARCH=arm aries_eur_defconfig

vi genera il .config per l’hardware del vostro samsung. I passaggi successivi sono

$ make ARCH=arm CROSS_COMPILE=/opt/arm-sourcery-g++-lite/bin/arm-none-linux-gnueabi-
$ make ARCH=arm CROSS_COMPILE=/opt/arm-sourcery-g++-lite/bin/arm-none-linux-gnueabi- zImage
$ make ARCH=arm CROSS_COMPILE=/opt/arm-sourcery-g++-lite/bin/arm-none-linux-gnueabi- modules

Fate attenzione che la toolchain deve essere nel vostro PATH. Se invece dovete buildare un modulo che non è contenuto nel tree dei sorgenti il comando da dare è il seguente

$ make ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PATH/$TOOLCHAIN_PREFIX -C /path/to/module/src

dall’interno del tree del kernel. Attenzione che per fare in modo che il modulo venga caricato senza problemi bisogna editare il config in modo che aggiunga un suffisso alla versione del  kernel che matchi quello che gira sul cellulare; per farlo dopo il primo step sopra descritto dare

$ make menuconfig ARCH=arm

ed editare

General setup  ---> Local version - append to kernel release

inserendo la stringa che trovate sotto la voce “Versione kernel” nella sezione “Info sul telefono” del vostro samsung. Senza questo sarebbe problematico riuscire a caricare i moduli compilati.

L’ultimo passaggio dovrebbe essere flashare il kernel usando heimdall. Saluti.


Buildare eseguibili per android

Posted: Ottobre 9th, 2011 | Author: | Filed under: Guide | Tags: , , , , , , , , | Commenti disabilitati su Buildare eseguibili per android

Un mio progetto segreto (?) durante l’hackit è stato capire come eseguire il cross-compiling su android;  come argomento pare essere già stato affrontato da altri ma senza che nessuno abbia prodotto un tutorial completo. Dopo una prima occhiata sull’argomento parrebbero esserci almeno N metodologie per cross-compilare su android (per chi non lo sapesse apparecchi come i nostri smartphone hanno un processore ARM).

Quello che segue può sembrare un po’ roba sparsa ed in tal caso c’avete ragione.

LIBC

Prima di tutto bisogna sapere che la libreria standard utilizzata per i processi che vengono eseguiti su questo sistema non è la glibc ma è chiamata bionic; questa è stata pensata per girare su sistemi embedded e quindi non ha tutte le potenzialità/funzionalità delle più note omologhe librerie , in particolare c’è da tener presente che non è supportata la gestione dei locale(7) direttamente da C ma bisogna passare da Java (per esempio wget non compila proprio per questa problematica e anche lua ha lo stesso problema). Inoltre ha una gestione propria dei thread (quindi niente original linux threads/NPTL ).

LINKER

Il linker è il programma che si deve preoccupare in un sistema operativo di caricare le librerie necessarie ad un adeguato programma; in linux è chiamato linux-vdso.so.1 mentre in android si è scelto di usare il programma il cui path è /system/bin/linker. Al contrario dei linker UNIX che rispettano la variabile d’ambiente LD_LIBRARY_PATH esso cerca solamente le librerie in /system/lib/ e /lib/ e questo è un casino. Qualche info

  • http://www.koushikdutta.com/2009/05/androids-linker-makes-baby-jesus-cry.html
  • http://groups.google.com/group/android-developers/browse_thread/thread/a76d1822ed0021ac
  • http://android.git.kernel.org/?p=platform/bionic.git;a=blob;f=linker/linker.c;h=00f36c07a663c25219d8d963c2b753914383bc11;hb=HEAD

Un modo per evitare i casini è buildare gli eseguibili staticamente.

SISTEMA DI BUILD DI ANDROID

Il sistema android utilizza una versione moddata di Makefile che si preoccupano di ricostruire le dipendenze, buildare librerie ed eseguibili e copiarle nella immagine disco da flashare nell’apparecchio.

L”unico problema è che non si possono utilizzare gli autotools o cmake ma si deve scrivere un makefile apposito, chiamato Android.mk, tramite cui effettuare la compilazione. Si capisce subito che se abbiamo già un progetto avviato e di una certa complessità è molto difficile scrivere uno di questi file senza problemi (e non dimentichiamoci del suo mantenimento successivo).

Siccome per adesso sono interessato a compilare programmi che già utilizzano gli autotools mostrerò come compilare staticamente/dinamicamente passando parametri opportuni a configure.

Per chi è interessato a compilare roba per android utilizzando CMake è interessante utilizzare le istruzioni per il cross compiling di openCV.

COMPILATORE

Per compilare ovviamente serve un compilatore e tutta la toolchain ed una prima opzione è la toolchain arm sourcery con la quale è possibile compilare staticamente; opzioni simili sono la toolchain della SDK ed NDK scaricabili dal sito di android. Il problema con queste due soluzioni è il dover elencare a manina tutti i flags necessari per linkare correttamente il programma al sistema di android che non è proprio un cazzo facile per le questioni espresse più sopra.

Proprio per questo una valida alternativa è il progetto droid-wrapper, esso si propone di creare uno script che configuri gcc ed ld per compilare programmi utilizzando i normali autotools. Ci si deve solo premurare di aver prima compilato i sorgenti di android.

Una volta scaricato il progetto con git è possibile facilitarne l’uso creando uno script che imposti le variabili d’ambiente in maniera corretta (la directory in cui è stato scaricato nel nostro caso è /opt/droid-wrapper/ con i sorgenti di android in /opt/android-source/)

$ cat .bash_droid
export DROID_ROOT=/opt/android-source/
export DROID_TARGET=generic
export PATH=/opt/droid-wrapper/bin/:$PATH

echo "usa CC=droid-gcc LD=droid-ld ./configure --host=arm-linux-eabi"

Una cosa da tener presente quando si effettua il cross compiling (cioè il compilare del codice per piattaforma diversa rispetto a quella in cui gira il compilatore) è la naming convention usata dai compilatori: un compilatore di questo tipo ha un prefisso costruito usando il seguente schema

arch-vendor-(os-)abi

Per esempio la toolchain della sourcery citata poco più sopra ha un prefisso dato da arm-none-linux-gnueabi. Tenete presente che la toolchain che vorrete usare deve essere nel vostro PATH altrimenti nulla compilerà.

Vediamo adesso come compilare alcuni tools utili per i very hackerz.

BUSYBOX

Busybox è un singolo programma che racchiude internamente praticamente tutte le utility UNIX ri-implementandole e permettendo così di avere un sistema funzionante con un singolo eseguibile anche in sistemi embedded. Nel caso di android questo risulta molto utile proprio per evitare di dover compilare tutti gli eseguibili necessari uno per uno.

Per compilarlo staticamente usando la toolchain prescelta basta eseguire

$ make menuconfig

e nel menù che compare,  inserire in

Busybox Settings > Build options > Cross Compiler prefix

l’identificativo della toolchain prescelta! Un make builderà per voi tutte le utility in un singolo eseguibile chiamato busybox.

BASH

Fila tutto liscio usando

$ ./configure --host=arm-none-linux-gnueabi --enable-static-link --without-bash-malloc

VIM

Un primo esempio di programma che può tornare utile a voi hackerz è il mitico editor: a causa della sua complessità non è possibile compilarlo dinamicamente; usiamo la toolchain sourcery

export PATH=/opt/arm-sourcery-g++-lite/bin:$PATH

Prima di tutto si necessita delle librerie ncurses che possono essere compilate con un semplice

$ ./configure --host=arm-none-linux-gnueabi && make

Chiamando NCURSES_PATH la variabile dove si imposta il path per le librerie appena sopra compilate

vim_cv_memmove_handles_overlap=no \
 vim_cv_toupper_broken=set \
 vim_cv_memcpy_handles_overlap=no \
 vim_cv_bcopy_handles_overlap=no \
 vim_cv_stat_ignores_slash=no \
 vim_cv_getcwd_broken=no \
 vim_cv_tty_group=world \
 vim_cv_terminfo=yes \
 LDFLAGS="-L$NCURSES_PATH/lib/ -static" \
 CFLAGS=-I$NCURSES_PATH/include/ ./configure --host=arm-none-linux-gnueabi --with-tlib=ncurses

Potrebbe uscire un errore al check per int32: per risolverlo editate src/auto/configure eliminando il controllo che ha restituito l’errore. Ma non è finita qui: dando make vi uscirà un errore

auto/osdef.h:117: error: previous declaration of 'tgoto' was here

e per risolverlo dovete andare ad eliminare le funzioni di cui si lamenta il compilatore definite in src/auto/osdef.h; finito ridate make. Finito di compilare potete caricare nel device il programma

adb push src/vim /data/local/tmp/

e lanciarlo da una shell con

TERM=xterm-color vim

Ovviamente così molte cose non funzioneranno alla perfezione, per esempio l’help.

Tutto questo è una rielaborazione di questo post http://credentiality2.blogspot.com/2010/08/native-vim-for-android.html.

EMULATORE

Si possono installare i programmi anche sull’emulatore tenendo conto che

  1. se si vuole installare roba nella cartella di sistema, bisogna rimontare la partizione /system in read-write mode (mount -o rw,remount -t yaffs2 /dev/block/mtdblock0 /system)
  2. è probabile che la partizione /system non sia grande abbastanza quindi si deve far partire l’emulatore con una size adeguata (emulator -avd test2.3.3 -partition-size 1024)

ROBA IN GENERALE

Per qualche info in più leggere


Exploit: prevenire NON è meglio che curare

Posted: Settembre 11th, 2011 | Author: | Filed under: Guide | Tags: , , , | Commenti disabilitati su Exploit: prevenire NON è meglio che curare

Eccoci alla seconda puntata di come capire il funzionamento degli exploit; l’ultima volta siamo rimasti alla potenziale modifica del flusso di un programma scritto male a nostro uso e consumo, oggi non andremo di molto avanti in quanto cercheremo di capire assieme come viene gestita la memoria relativa ad un processo in un OS moderno. Partire subito con esempi di exploit non sarebbe utile perché gli esempi semplici praticamente non esistono: il primo paper di Aleph1 risale al 1996 e da allora i sistemi informatici si sono evoluti con contromisure proprio atte a evitare il succedersi di intrusioni alzando sempre di più l’asticella della difficoltà insita nel deviare il $pc tanto agognato.

C’è da dire che benché molti sforzi siano stati fatti, la genialità degli exploiter è cresciuta altrettanto portando questa pratica ad uno stato quasi magico. Ma bando alle ciance e iniziamo ad analizzare come è strutturato un programma (mi limiterò al formato eseguibile ELF of course).

Teoria

Nella prima parte abbiamo visto come un programma funziona a livello di istruzioni, ma per eseguire istruzioni un programma ha prima di tutto bisogno di essere caricato in memoria; bisogna tenere conto che ci saranno zone di memoria apposite per ogni tipo di necessità, elenchiamole:

  • Stack: visto sempre nella puntata precedente, contiene le variabili locali del contesto di esecuzione più le variabili della funzione attualmente in esecuzione
  • File mappings: esiste la possibilità di mappare direttamente file in memoria ed è anche il metodo con cui vengono caricate le shared library (ne parlerò un po’ meglio dopo)
  • Heap: zone di memoria allocate dinamicamente (in pratica malloc() et familia)
  • BSS: variabili statiche non inizializzate
  • Data: variabili statiche inizializzate
  • Text: contiene il codice eseguibile

Ognuna di queste sezioni ha ovviamente delle proprietà sue proprie, in particolare può essere scrivili,leggibile ed eseguibile. Per avere un esempio pratico eseguiamo

$ cat /proc/self/maps
08048000-08052000 r-xp 00000000 08:21 8421442    /bin/cat
08052000-08053000 rw-p 0000a000 08:21 8421442    /bin/cat
0875a000-0877b000 rw-p 00000000 00:00 0          [heap]
b74bc000-b76bc000 r--p 00000000 08:21 1035297    /usr/lib/locale/locale-archive
b76bc000-b76bd000 rw-p 00000000 00:00 0
b76bd000-b7810000 r-xp 00000000 08:21 29540827   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7810000-b7811000 ---p 00153000 08:21 29540827   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7811000-b7813000 r--p 00153000 08:21 29540827   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7813000-b7814000 rw-p 00155000 08:21 29540827   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7814000-b7817000 rw-p 00000000 00:00 0
b784a000-b784c000 rw-p 00000000 00:00 0
b784c000-b784d000 r-xp 00000000 00:00 0          [vdso]
b784d000-b7868000 r-xp 00000000 08:21 29540776   /lib/i386-linux-gnu/ld-2.13.so
b7868000-b7869000 r--p 0001b000 08:21 29540776   /lib/i386-linux-gnu/ld-2.13.so
b7869000-b786a000 rw-p 0001c000 08:21 29540776   /lib/i386-linux-gnu/ld-2.13.so
bfb95000-bfbb6000 rw-p 00000000 00:00 0          [stack]

Come potete vedere vengono visualizzati i vari mappings che il programma ha nella sua esecuzione; per capire cosa significhi ‘sta roba ecco a voi la pagina di man

/proc/[pid]/maps
 A file containing the currently mapped memory regions and their access permissions.

 The format is:

 address           perms offset  dev   inode   pathname
 08048000-08056000 r-xp 00000000 03:0c 64593   /usr/sbin/gpm
 08056000-08058000 rw-p 0000d000 03:0c 64593   /usr/sbin/gpm
 08058000-0805b000 rwxp 00000000 00:00 0
 40000000-40013000 r-xp 00000000 03:0c 4165    /lib/ld-2.2.4.so
 40013000-40015000 rw-p 00012000 03:0c 4165    /lib/ld-2.2.4.so
 4001f000-40135000 r-xp 00000000 03:0c 45494   /lib/libc-2.2.4.so
 40135000-4013e000 rw-p 00115000 03:0c 45494   /lib/libc-2.2.4.so
 4013e000-40142000 rw-p 00000000 00:00 0
 bffff000-c0000000 rwxp 00000000 00:00 0

 where "address" is the address space in the process that it occupies, "perms" is a set of permissions:

 r = read
 w = write
 x = execute
 s = shared
 p = private (copy on write)

 "offset"  is  the  offset  into  the  file/whatever,  "dev" is the device (major:minor), and "inode" is the inode on that
 device.  0 indicates that no inode is associated with the memory region, as the case would  be  with  BSS  (uninitialized
 data).

 Under Linux 2.0 there is no field giving pathname.

Piccolo appunto: se controllate i mappings in vari programmi eseguiti contemporanemente potreste chiedervi come mai c’è un overlap fra le varie regioni di memoria fra programmi diversi e la spiegazione è semplice: ogni programma ha a disposizione virtualmente 3GB di memoria flat, è il sistema operativo che si preoccupa di eseguire i mappings virtuale/fisico in maniera corretta.

Tornando all’ouput di cui sopra potete vedere che tutte le zone di memoria elencate sono presenti con in più una zona chiamata vdso (Virtual Dynamic Shared Object) che si preoccupa di fare da trampolino per le syscall (invenzione di linus che dichiara “I’m a disgusting pig, and proud of it to boot.“)

Prendiamo il seguente programma

#include<stdio.h>
#include<string.h>

int main(int argc, char* argv[]) {
 char* unitialized;
 static char* s_unitialized;
 char initialized[] = "porcamadonna";
 static char s_initialized[] = "porcamadonna";

 printf("process %d \n"
  "\t       uninitialzed: 0x%08x\n"
  "\tstatic uninitialzed: 0x%08x\n"
  "\t       initialized:  0x%08x\n"
  "\tstatic initialized:  0x%08x\n",
  getpid(), &unitialized, &s_unitialized, &initialized, &s_initialized);

 int iMustWait = !(argc > 1 && ! strcmp(argv[1], "-go"));
 if (iMustWait)
  getchar();

 return 0;
}

e compiliamolo

$ gcc segment.c -o segment

Una volta lanciato si bloccherà mostrandoci gli indirizzi di memoria assegnati alle variabili

$ ./segment
process 11663
        uninitialzed: 0xbf9e3ad8
 static uninitialzed: 0x08049804
        initialized:  0xbf9e3acb
 static initialized:  0x080497ec

Se controlliamo il map del programma in esecuzione

$ cat /proc/11663/maps
08048000-08049000 r-xp 00000000 08:13 3556546    /home/packz/Programmazione/Ci/Exploit/Data segment/segment
08049000-0804a000 rw-p 00000000 08:13 3556546    /home/packz/Programmazione/Ci/Exploit/Data segment/segment
b76ad000-b76ae000 rw-p 00000000 00:00 0
b76ae000-b7801000 r-xp 00000000 08:21 29540770   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7801000-b7802000 ---p 00153000 08:21 29540770   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7802000-b7804000 r--p 00153000 08:21 29540770   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7804000-b7805000 rw-p 00155000 08:21 29540770   /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
b7805000-b7808000 rw-p 00000000 00:00 0
b7839000-b783d000 rw-p 00000000 00:00 0
b783d000-b783e000 r-xp 00000000 00:00 0          [vdso]
b783e000-b7859000 r-xp 00000000 08:21 29540856   /lib/i386-linux-gnu/ld-2.13.so
b7859000-b785a000 r--p 0001b000 08:21 29540856   /lib/i386-linux-gnu/ld-2.13.so
b785a000-b785b000 rw-p 0001c000 08:21 29540856   /lib/i386-linux-gnu/ld-2.13.so
bf9c4000-bf9e5000 rw-p 00000000 00:00 0          [stack]

possiamo vedere che le variabili statiche (cioé globali all’interno del flusso del programma) sono nello spazio di memoria indicato nella seconda riga. Le altre sono nello spazio dello stack (ultima riga).

Tuttavia fra le due variabili statiche c’è una leggera differenza: se andiamo a vedere con readelf i section headers scopriamo che la variabile inizializzata punta alla sezione .data, mentre quella non inizializzata alla sezione .bss

$ readelf -S segment
There are 31 section headers, starting at offset 0x934:

Section Headers:
 [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
 [ 0]                   NULL            00000000 000000 000000 00      0   0  0
...
 [25] .data             PROGBITS        080497e4 0007e4 000018 00  WA  0   0  4
 [26] .bss              NOBITS          080497fc 0007fc 00000c 00  WA  0   0  4
...
 [30] .strtab           STRTAB          00000000 00126c 00024a 00      0   0  1
Key to Flags:
 W (write), A (alloc), X (execute), M (merge), S (strings)
 I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
 O (extra OS processing required) o (OS specific), p (processor specific)

Un ulteriore segmento di memoria è quello denominato heap che è associato con l’allocazione dinamica di memoria (si pensi alle varie malloc(), calloc() e free()). A livello implementativo sono variazioni della chiamata di sistema brk() che per esempio nelle libc è eseguita tramite la Doug Lea’s malloc; se avrò tempo un giorno potrei scrivere come eseguire exploit dall’heap, pratica molto diffusa nei browser.

L’argomento che rimane da discutere è il caricamento delle librerie dinamiche che necessità l’eseguibile e ciò avviene tramite l’uso dell’interpreter (nei sistemi linux rappresentato da /lib/linux-so.2). In realtà quando un file eseguibile viene lanciato (funzione load_elf_binary in fs/binfmt.c), il kernel si preoccupa di leggere dall’apposita sezione del file ELF proprio quale è il suo interpreter  e dopo aver impostato opportunamente le zone di memoria carica le librerie necessarie al funzionamento del programma tramite esso. Se interessa il codice di ld.so si trova nella directory elf/ del tree delle libc; il suo punto di ingresso è la funzione dl_main in rtld.c.

Siccome le librerie vengono caricate a run-time esiste un processo chiamato di relocation che avviene all’interno di un processo ELF quando si necessità di eseguire una routine appartenente ad una libreria esterna: se disassembliamo il programma segment, possiamo vedere che alla riga in cui viene eseguita la call alla printf, la jump salta alla sezione .plt del nostro eseguibile

$gdb segment
Reading symbols from /home/packz/Programmazione/Ci/Exploit/Data segment/segment...(no debugging symbols found)...done.
(gdb)disassemble main
...
0x080484ad <+89>:    call   0x8048350 <printf@plt>
...

Se disassembliamo quella sezione otteniamo

$ objdump -j .plt -d segment

segment:     file format elf32-i386

Disassembly of section .plt:

08048340 <printf@plt-0x10>:
 8048340:       ff 35 c8 97 04 08       pushl  0x80497c8
 8048346:       ff 25 cc 97 04 08       jmp    *0x80497cc
 804834c:       00 00                   add    %al,(%eax)
 ...

08048350 <printf@plt>:
 8048350:       ff 25 d0 97 04 08       jmp    *0x80497d0
 8048356:       68 00 00 00 00          push   $0x0
 804835b:       e9 e0 ff ff ff          jmp    8048340 <_init+0x38>

Se in gdb andiamo a vedere che indirizzo c’è scritto alla cella di memoria 0x80497d0

(gdb) x/a 0x80497d0
0x80497d0 <printf@got.plt>:    0x8048356 <printf@plt+6>

con stupore scopriamo che punta alla istruzione successiva. Seguendo il flusso delle istruzioni vediamo che viene pushato un numero (l’indice della funzione da relocare) e avviene una jump all’inizio della sezione .plt; viene pushato un indirizzo (?) e si salta alla routine (call *0x80497cc) che andrà a risolvere la routine printf. L’indirizzo di quest’ultima jump è riempito dal linker all’avvio del programma.

Finita la routine all’indirizzo 0x80497d0 si ritroverà direttamente l’indirizzo della funzione in questione così da non aver più necessità di rieseguire tutto la relocazione alla prossima invocazione della printf. La Procedure Linkage Table e la Global Offset Table hanno un ruolo molto importante nella scrittura degli exploit avanzati, spero di poterlo spiegare in futuro.

Dopo tutta la teoria

Dopo tutto questo viaggio sulle varie zone di memoria possiamo passare al collegare questo con la sicurezza di un eseguibile: per prima cosa c’è da notare che se andiamo ad eseguire lo stesso programma due volte e controlliamo gli indirizzi assegnati alle varie aree di memoria scopriamo che tutti gli indirizzi tranne quelli per il codice e dei dati globali sono cambiati, in particolare sono randomizzati.

Questa è una delle prime contromisure sviluppate nel corso degli anni per prevenire i buffer overflow: se gli indirizzi cambiano ogni volta non è così facile scrivere un exploit che funzioni correttamente.

Per sapere come è implementata la randomizzazione leggetevi questo post: https://xorl.wordpress.com/2011/01/16/linux-kernel-aslr-implementation/.

Secondo step di protezione è lo stack non eseguibile (NX): siccome il codice per l’exploit viene posto (solitamente) nello stack e si cerca di eseguirlo da lì, rimuovendo dalle pagine di memoria dello stack il bit eseguibile provoca un segmentation fault quando l’istruction pointer viene dirottato in quelle zone. Come si nota l’unica zona eseguibile è quella text e le librerie condivise.

Terzo step di protezione è l’anteporre al frame dello stack dei valori random che vengono chiamati canary values da controllare al termine di una routine per la loro corruzione: siccome un buffer overflow dovrà per forza passare attraverso questi valori corrompendoli, la protezione dovrebbe essere effettiva.

L’ultimo livello di protezione è la cosiddetta ASCII-Armor, cioé caricare librerie  con indirizzi contenenti un byte nullo in maniera da rendere impossibile utilizzare tali indirizzi in un payload.

Purtroppo(?) tutte queste contromisure sono (per la maggior parte dei casi)  inutili, un eseguibile ha dentro di se abbastanza spazio di azione da rendere un overflow exploitabile nella maggioranza dei casi; nei post futuri spero di riuscire a spiegare come.


Exploit: intro

Posted: Agosto 20th, 2011 | Author: | Filed under: Guide | Tags: , , , , | 2 Comments »

L’hacking da che mondo e mondo tratta l’usare uno strumento in un modo non concepito dal suo inventore; chi si occupa di programmazione e non solo si deve preoccupare in maniera critica di non esporre il proprio lavoro a mani poco scrupolose. Io non mi ritengo un esperto ma ci sono alcune cose che mi affascinano, tra queste la programmazione a basso livello e gli exploit (due cose molto legate tra loro).

Chi si fosse chiesto come sia possibile entrare in un computer altrui questo vuol essere un intro non esauriente (spero ulteriori posts seguiranno) che possa gettare luce.

Partiamo da un programma molto semplice

int bau(char* porcodio, int alpha) {
    return porcodio[0] + alpha;
}
 
int main(int argc, char* argv[]) {
    return bau("bastardo", 137);
}

Questo programma non fa niente di utile (se non un po’ di blasfemia spicciola) ma servirà a noi per capire come funziona sotto il cofano un programma per computer (quanto segue è tutto eseguito su sistemi x86).

Per prima cosa compiliamolo

$ gcc boh.c -o boh

e lanciamolo controllando il valore di ritorno

$ ./boh
$ echo $?
235

Entusiasmante vero (235 = ‘p’+ 137 dove il valore ASCII di “p” è 98)? ok, adesso proviamo a vedere passo passo cosa succede; utilizziamo il fido compagno di ogni programmatore, il prode gdb: lanciamolo e impostiamolo in maniera tale da fermarsi alla funzione main e mostrare le istruzioni a livello assembler

$ gdb -q ./boh
Reading symbols from /sti/cazzi/boh...(no debugging symbols found)...done.
(gdb) b main
Breakpoint 1 at 0x80483cb
(gdb) display /3i $pc

Piccolo appunto: il linguaggio assembler è il linguaggio a più basso livello con cui si può dialogare con un processore ed è ovviamente unico per ogni tipologia di architettura: l’assembler per x86 è diverso da quello per x86_64 e quello per ARM, ognuno ha le sue peculiarità ma la cosa più importante è capire che sono simili ma incompatibili.

Per chi non conoscesse il linguaggio assembler un piccolo riassunto: siccome parla con il processore le sue variabili possono essere solo i vari registri del processore stesso; in un sistema x86 si hanno i registri eax, ebx, ecx, edx che sono registri generici più dei registri più specifici come %ebp e %esp che gestiscono lo stack di cui parleremo più diffusamente subito dopo. Un registro molto importante è %eip che punta  all’indirizzo di memoria che contiene la prossima istruzione da eseguire (in gdb è $pc non so perché).

Lo stack è una parte fondamentale del sistema: è in pratica una area di memoria che contiene le variabili che una data routine deve gestire; infatti siccome i registri sono in numero limitato si ha bisogno di definire una area di memoria per gestire i dati. Lo stack permette di isolare le variabili locali proprie di una data routine definendo la base dello stack (puntata dal registro %ebp) e la cima dello stack (puntata dal registro %esp). Le istruzioni assembler per gestire lo stack sono push e pop, la prima inserisce nello stack il valore del registro indicato come argomento, il secondo invece fa l’opposto; la posizione nello stack è indicata da %esp che viene decrementato nel primo caso e incrementato nel secondo (nei sistemi x86 lo stack cresce verso il basso). In pratica lo stack è una coda LIFO (Last In First Out).

Facciamo girare il nostro programma e vediamo cosa succede in pratica

(gdb) r
Starting program: /sti/cazzi/boh 

Breakpoint 1, 0x080483cb in main ()
1: x/3i $pc
=> 0x80483cb <main+6>:    movl   $0x89,0x4(%esp)
 0x80483d3 <main+14>:    movl   $0x80484b0,(%esp)
 0x80483da <main+21>:    call   0x80483b4 <bau>

L’istruzione puntata dalla freccia muove nello stack il valore 137 mentre quella seguente mette la stringa “bastardo”

(gdb) x/s 0x80484b0
0x80484b0:     "bastardo"

Infine, l’ultima istruzione, chiama la funzione bau. Il perché di questa procedura consiste nel fatto che i parametri di una funzione devono essere passati nello stack in ordine inverso rispetto all’ordine nella definizione. Ultimo particolare da sapere è che l’istruzione call fa una push nello stack del registro %eip e salta all’indirizzo indicato come argomento.

Saltiamo alla funzione bau() eseguendo il comando si 3 volte così da ritrovarci in quello che viene chiamato prologo

0x080483b4 in bau ()
1: x/3i $pc
=> 0x80483b4 <bau>:    push   %ebp
 0x80483b5 <bau+1>:    mov    %esp,%ebp
 0x80483b7 <bau+3>:    mov    0x8(%ebp),%eax

Le prime due istruzioni sono chiamate in questo modo perché definiscono il frame per la funzione corrente, cioè il contesto in memoria dove collocare le variabili locali che saranno utilizzate da questa funzione; per farlo si imposta la base dello stack a coincidere con la cima dello stack. Tutto preceduto dal salvataggio del frame della precedente funzione.

In gdb è possibile ricavare questa info comodamente

(gdb) info frame
Stack level 0, frame at 0xbffff310:
 eip = 0x80483b7 in bau; saved eip 0x80483df
 called by frame at 0xbffff320
 Arglist at 0xbffff308, args:
 Locals at 0xbffff308, Previous frame's sp is 0xbffff310
 Saved registers:
 ebp at 0xbffff308, eip at 0xbffff30c

Quindi riassumendo, all’avvio di una nuova funzione nello stack saranno posizionate le seguenti variabili

secondo argomento
primo argomento
indirizzo di ritorno
vecchio ebp

una sopra l’altra. Sempre gdb ci aiuta

(gdb) x/4a $ebp
0xbffff308:    0xbffff318    0x80483df <main+26>    0x80484b0    0x89

Se analizziamo in toto la funzione bau, possiamo notare quello che si chiama epilogo nelle due ultime righe

(gdb) disassemble bau
Dump of assembler code for function bau:
 0x080483b4 <+0>:    push   %ebp
 0x080483b5 <+1>:    mov    %esp,%ebp
=> 0x080483b7 <+3>:    mov    0x8(%ebp),%eax
 0x080483ba <+6>:    movzbl (%eax),%eax
 0x080483bd <+9>:    movsbl %al,%eax
 0x080483c0 <+12>:    add    0xc(%ebp),%eax
 0x080483c3 <+15>:    pop    %ebp
 0x080483c4 <+16>:    ret   
End of assembler dump.

il cui scopo è ripristinare il frame precedente e riportare il flusso di esecuzione a dove era stata chiamata la funzione bau() recuperando dallo stack l’indirizzo di ritorno (ricordate cosa fa call? fa una push del registro %eip, ret lo recupera).

Bene, direte voi, ma chi se ne frega? vogliamo vedere la ciccia!!1!!!! Ok, state calmi, passiamo ad un altro programma tipo questo

int main(int argc, char* argv[]){
    char buffer[256];
    return strcpy(buffer, argv[1]);
}

Questo programma ha un difetto sostanziale, non controlla l’input dell’utente! abbiamo un buffer che può contenere 256 fucking char (grossi un byte) e ci copiamo dentro (senza fucking controllare) il primo argomento passato alla funzione. Quando non si controlla quello che si inserisce lato utente aspettatevi un problema, può essere un programma in C, in PHP o un controller di una view di una webapp.

Se proviamo a lanciare il programma passandogli 300 caratteri “A” cosa succede?

$ ./c `python -c 'print "A"*300'`
Errore di segmentazione (core dumped)

Oh, crasha! mio dio. Ma non finisce qui, se controlliamo con gdb il file core che ha creato scopriamo una cosa interessante

$ gdb -q ./c core
Reading symbols from /tmp/c...(no debugging symbols found)...done.
[New Thread 19714]

warning: Can't read pathname for load map: Errore di input/output.
Reading symbols from /lib/i386-linux-gnu/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/i386-linux-gnu/i686/cmov/libc-2.13.so...done.
done.
Loaded symbols for /lib/i386-linux-gnu/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./c AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
#0  0x41414141 in ?? ()

per capirci

(gdb) print $pc
$1 = (void (*)()) 0x41414141

Abbiamo sovrascritto il registro $pc, cioè (in teoria) abbiamo modificato il flusso del programma!!!Questo è successo semplicemente perché strcpy() è andata a copiare a partire dalla parte dello stack in cui era definita la variabile buffer andando a sbordare sopra il frame precedente e sovrascrivendo sia il vecchio %ebp che %eip. Infatti controllando i registri si conferma quanto detto

(gdb) info register
eax            0xbfce7c20    -1076986848
ecx            0x0    0
edx            0x12d    301
ebx            0xb76d3ff4    -1217576972
esp            0xbfce7d30    0xbfce7d30
ebp            0x41414141    0x41414141
esi            0x0    0
edi            0x0    0
eip            0x41414141    0x41414141
eflags         0x10246    [ PF ZF IF RF ]
cs             0x73    115
ss             0x7b    123
ds             0x7b    123
es             0x7b    123
fs             0x0    0
gs             0x33    51

Certo la strada è ancora lunga, ma in potenziale possiamo aprire una shell, ma questo è argomento di una prossima puntata.


Piccolo vademecum per il programmatore

Posted: Agosto 22nd, 2008 | Author: | Filed under: Guide, Programmazione | 1 Comment »

Regole da seguire per scrivere codice in C

  1. Appena apri un file (sopratutto non tuo) imposta shiftwidth, tabstop ed eventualmente expandtab in maniera adeguata al tuo stile. Eventualmente set list ti può far capire che impostazioni sono state usate.
  2. Il preprocessore ti ha fatto conoscere # e ## che sono tue amiche e ci sanno fare.
  3. Ricordati che con -llibrary dici al linker che al programma serve la libreria library e con -L eventualmente dove trovarla. Un controllo con ldd non fa mai male.
  4. Commenta il codice
  5. Commenta il codice
  6. Se hai creato una funzione con più di due blocchi distinti mi sa che ti tocca riscriverla.
  7. Ricordati di nascondere con static una funzione al mondo esterno.
  8. Non sforare le 80 colonne.
  9. Sempre sia lodato ulimit -c unlimited.
  10. Quando migliori il codice assicurati di non peggiorarlo.
  11. I Makefile sono una figata
  12. Se il tuo programma prevede di scrivere su file usa full(4) per provare cosa succede nel caso si esaurisca lo spazio su disco (tu ovviamente credevi di aver pensato a tutto!!!).
  13. Le mailing list sono tue amiche (magari leggile tramite thunderbird che ha un eccellente sezione sulla iscrizione ai news groups di gmane.org).
  14. Se desideri open(2) ma vim ti apre open(1) ricordati di premere ‘2K‘.
  15. If a macro contains more than one statement, use a do/while structure to enclose the
    macro. (Don’t forget to leave out the semicolon of the statement).
  16. gcc -dM -E - < /dev/null può dirti quali sono le macro predefinite nel tuo compilatore preferito.
  17. Se per caso devi utilizzare le feature_test_macros(7), ricordati di inserire i #define prima di qualunque altro #include.
  18. Puoi impostare un campo di una struct tramite per esempio
    variabile_struct = (struct punto){ .x = 10.0 , .y = 14.89 }; secondo me è più leggibile e anche se cambi la definizione della struct non hai bisogno di cambiare l’ordine delle inizializzazioni (e il compilatore non ti avverte!!!).
  19. Usa -Wpadded, -Wpacked e nel caso utilizza __attribute__ ((__packed__)) per controllare l’alignment ed il padding di una struct. Utile se usi una fread su un file binario e gli elementi della struct non sono caricati correttamente.
  20. Usa un regola esplicita nel makefile per gli header: file.o: header.h. Altrimenti nella ricompilazione può usare una struct che in realtà è stata ridefinita e il segfault diventa un mistero.
  21. Quando definisci un file oggetto come libreria, con il nome per esempio "cazzo-util.c", includi in esso l’header "cazzo-util.h" così da avere sotto controllo eventuali definizioni diverse di funzione.
  22. extern va in .h
  23. Se devi leggere un double con scanf, devi usare il modificatore "long", cioè %lf,  porcatroia…
  24. Magari inizi a scrivere un po’ di funzioni static in un unico file e poi in un secondo tempo vuoi spostare per argomento in altri file queste, puoi usare sed(1) usando come pattern ‘/^static.*(/,/^}/p’ per studiartele un attimo.
  25. Usa valgrind per controllare memory leak: ‘valgrind –tool=memcheck <programma e argomenti>‘.
Compiling.
Linkografia

Shared library or something like this

Posted: Luglio 19th, 2008 | Author: | Filed under: Guide, Programmazione | Commenti disabilitati su Shared library or something like this

Sto riscrivendo dei miei esempi di codice in C e ho varie routine di X11 da modificare in maniera tale da farle lavorare come librerie shared e poterle condividere facilmente tra i vari programmi che scrivo; visto che ogni volta mi incasino per farle funzionare perché non mi ricordo le flags da passare al compilatore/linker qui metto i miei tricks. Per adesso scrivo questo poi metto apposto tutto (sono reduce da una serata di alcol).

Dalla pagina di manuale di gcc(1)

-llibrary
-l library
           Search the library named library when linking.  (The second
           alternative with the library as a separate argument is only for
           POSIX compliance and is not recommended.)

           It makes a difference where in the command you write this option;
           the linker searches and processes libraries and object files in the
           order they are specified.  Thus, foo.o -lz bar.o searches library z
           after file foo.o but before bar.o.  If bar.o refers to functions in
           z, those functions may not be loaded.

           The linker searches a standard list of directories for the library,
           which is actually a file named liblibrary.a.  The linker then uses
           this file as if it had been specified precisely by name.

           The directories searched include several standard system
           directories plus any that you specify with -L.

           Normally the files found this way are library files—archive files
           whose members are object files.  The linker handles an archive file
           by scanning through it for members which define symbols that have
           so far been referenced but not defined.  But if the file that is
           found is an ordinary object file, it is linked in the usual
           fashion.  The only difference between using an -l option and
           specifying a file name is that -l surrounds library with lib and .a
           and searches several directories.

  Ricordarsi che per passare opzioni direttamente al linker si necessita della flag -Wl,<Opzione>,<valore>. Molto comoda l’opzione -rpath (vedi ld(1)).


La tastiera in Linux

Posted: Gennaio 15th, 2008 | Author: | Filed under: Guide | 3 Comments »

Una parte fondamentale della interazione con il nostro amato sistema operativo e proprio la tastiera che ci permette di inserire i comandi, i dati e quant’altro necessitiamo per la interazione con esso. Read the rest of this entry »


Vim

Posted: Dicembre 10th, 2007 | Author: | Filed under: Guide, Programmazione | 1 Comment »

Vi Vi Vi the editor of the beast

Nel 1976 nasce per mano di Bill Joy quello che diventerà l’editor per eccellenza degli hacker negli anni a venire, il mitico Vi: nome derivato dalle iniziali del comando visual prende vita dall’editor ex, editor ancora precedente a sua volta derivato da ed

Read the rest of this entry »


X Window system

Posted: Agosto 10th, 2007 | Author: | Filed under: Guide, Programmazione | Commenti disabilitati su X Window system

( GUIDA IN VIA DI COMPLETAMENTO)

Xorg logo.

Nei sistemi Unix-like il gestore grafico standard è il cosidetto X Window system, sistema nato nel 1984 al MIT (da cui eredita la licenza), successore del gestore grafico W il quale girava sul sistema operativo V (notare come le lettere siano in successione). In linux si ha avuto la possibilità di usarlo dalla versione 0.95 della primavera del 1992 grazie alla implementazione (primitiva ai tempi) dei socket fatta da Orest Zborowsky[1].

Read the rest of this entry »


Makefile

Posted: Giugno 20th, 2007 | Author: | Filed under: Guide | 1 Comment »

Uno degli splendidi strumenti costruiti dai programmatori del mondo Unix è rappresentato dal programma make che ha lo scopo di aiutare uno sviluppatore nello sviluppo di progetti di grosse dimensioni tenendo conto in automatico quali file sono stati modificati e dunque necessitano operazioni su di esse.

Read the rest of this entry »