Il comando inforegister su gdb è il modo migliore per andare a vedere che cosa contenga un registro. La shell con path più breve da eseguire → /bin/sh, che è lunga 7 caratteri come path, con al massimo anche 8 caratteri con il carattere di terminazione. L’idea sarebbe andare a caricare la shell con execve in C. Questo prende un path name e poi le varie ed eventuali variabili di ambiente. Fa un piccolo ripasso di API e ABI. Cosa interessante: una funzione di libreria mi permette di spingere sullo stack gli argomenti, mentre le chiamate di sistemi non mi permette di farlo. Ho due stack: applicativo e del kernel. Quello del kernel quando un programma gira in kernel mode. Non posso passare da kernel a mode ad application mode come se niente fosse, ho proprio due sistemi divisi da questo punto di vista. Per fare una chiamata di sistema, devo per forza usare i registri e ogni architettura o sistema operativo ha differenti registri. Quando siamo su intel x86 e gnu/linux devo configurarmi come in slide 256.
Quindi ricapitolando: mi serve andare a rappresentare i dati della shell, il puntatore nullo e la chiamata a execve. Dove li metto? Sui registri opportuni e sullo stack.
Prima problema: devo andare a gestire uno zero e posso andare a farlo con l’operazione di xor %eax, %eax. Questo perché è molto più conveniente e veloce andare a gestire tutto quanto con lo xor, piuttosto che con i move.
Questo valore ora lo spingo sullo stack con push %eax. Quindi ho prodotto uno zero e so come andarlo a chiamare. Poi devo andare a spingere /bin/sh al contrario come valore esadecimale. Questo valore sarebbe in teoria //sh, questo perché sto in una architettura in 32 bit ed è comodo lavorare con multipli di 4 o 8 byte. Se non chiudo correttamente devo fare padding essenzialmente con uno zero, ma sto introducendo uno zero esplicito nello share code. Successivamente spingo anche /bin con lo stesso modo. Se fai dei test per altro vedi che lo slash sia idem potente e lo puoi mettere quanto vuoi //////////bin/sh funziona perfettamente.
Infine sposto la cima dello stack pointr con mov %eax, %ecx per andare a puntare effettivamente /bin/sh. Finisco altre due mov e chiudo tutto. Adesso dovrei andare a cercare nella syscall_32.tbl per vedere execve e come è wrappata e gestita.
Spesso c’è detecting di cose strane che passano in assembly. L’exploit che scrivete funzionano solamente nell’ambiente in cui lo scrivo. Devo stare attento perché la shell che trovo da terminale dal debugger è diversa in termini di env da quella normale perché ho una definizione dello spazio dello schermo come linee e colonne. E’ letale perché se andiamo a contare quanto spazio consumano lines and colonne. Questo vuol dire che il buffer di sposta (32 byte) di un tot di byte quando vado ad eseguire l’exploit da dentro il debugger. L’intuizione è che il buffer è 32 byte più corto di quando eseguo lo stesso comando via shell normale e non via gdb. Questo lo notiamo nelle ctf quando una challange funziona localmente ma per colpa di un disallineamento non potrebbe funzionare su altri sistemi.
[03-04-2023]
Sto cercando di andare a ricostruire lo stack, il pezzo di stack che questa chiamata provoca e fare in modo che sull’indirizzo della cella contenente l’indirizzo di ritorno ci sia l’indirizzo di system, l’indirizzo di ritorno da system e poi il parametro di system. Cosa ha a disposizione:
Mettendo insieme il tutto potrei eseguire anche funzioni di libreria arbitraria. Sto cercando di emulare un mini stack di una funzione a mano e forzare l’esecuzione di una funzione arbitraria.
Vedi la follia di pop per andare a fare invocazioni a funzioni. Vedi gadget. Praticamente faccio del pop per muovermi sullo stack per concatenare delle funzioni arbitrarie una dietro l’altra.