Duda sobre buffer overflow

Iniciado por pianista, 23 Diciembre 2011, 14:48 PM

0 Miembros y 2 Visitantes están viendo este tema.

pianista

Hola qué tal?

A ver, tengo una duda que no me está permitiendo avanzar en este campo.

Empecé a leer el libro de shellcoders sobre exploits, entonces uno de los primeros ejemplos del libro es:


void return_input(void)
{
char array[30];

gets(array);
printf("%s\n",array);
}

main()
{
return_input();

return 0;
}



Vale, la idea es la siguiente:

Desensamblas con gdb la parte del main y obtienes la dirección a la que se invoca al return_input, con el fin de desbordar el buffer para que lo ejecute dos veces.

Aquí llega la cuestión, desesamblando me saca (por poner un ejemplo):

0x080483ed <main+3> call 0x80483c4 <return_input>

Y desbordo el buffer como indica el libro :
printf "AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDD\xed\x83\x04\x08"|./overflow

Ahí está la cuestión, que no logro de ninguna manera que no dé segmentation fault, y que me repita dos veces la llamada al return_input

Estoy usando wifislax 2.0, que aquellos kernel y gcc y tal, no llevaban protecciones overflow, pero claro, yo lo que pienso es lo siguiente:

Cómo coño va  afuncionar, esa dirección que saca el gdb, no tiene por qué coincidir con la que haya en tiempo de ejecución, no???

Saludos y espero ayuda, que me encantaría iniciarme en profundidad, aunque ya he visto que el tema en los últimos años, ha ido poniendo muchísimas protecciones.




Sagrini

Tal vez la dirección no esté bien sobreescrita, no sea la correcta... :P Ponnos la salida de GDB.

pianista

Muy bien, esta es la salida del gdb:


Dump of assembler code for funcion main:
0x080483d2 <main+0>: push %ebp
0x080483d3 <main+1>: mov %esp,%ebp
0x080483d5 <main+3>: call 0x80483b4 <return_inpu>
0x080483da <main+8>: mov $0x0,%eax
0x080483df <main+13>: pop%ebp
0x080483e0 <main+14>: ret


Entiendo que habría que lograr escribir la dirección 0x080483d5 que es donde se hace la invocación a return_input y para ello emplearía :
\xd5\x83\x04\x08

Saludos

Sagrini

TODA la salida de GDB. Incluye el resultado cuando corres el programa desde GDB.

Ivanchuk

Cita de: pianista en 23 Diciembre 2011, 14:48 PM
Cómo coño va  afuncionar, esa dirección que saca el gdb, no tiene por qué coincidir con la que haya en tiempo de ejecución, no???

Si, esa direccion es la misma, esta en duro en la cabecera del ejecutable. Lo que te puede cambiar es la dir de la pila.

Código (bash) [Seleccionar]
readelf -S a.out | grep .text

Cita de: pianista en 23 Diciembre 2011, 16:26 PM
Muy bien, esta es la salida del gdb:


Dump of assembler code for funcion main:
0x080483d2 <main+0>: push %ebp
0x080483d3 <main+1>: mov %esp,%ebp
0x080483d5 <main+3>: call 0x80483b4 <return_inpu>
0x080483da <main+8>: mov $0x0,%eax
0x080483df <main+13>: pop%ebp
0x080483e0 <main+14>: ret


Entiendo que habría que lograr escribir la dirección 0x080483d5 que es donde se hace la invocación a return_input y para ello emplearía :
\xd5\x83\x04\x08

Tenes que poner la dir justo despues del call, la 0x080483da.

Saludos !
Sólo quien practica lo absurdo puede lograr lo imposible.

Join us @ http://foro.h-sec.org

Sagrini

Un último detalle sería decir que para comprobar si funciona correctamente, sería mejor declarar una función que no se llamase en el programa, y hacer que se ejecute con el retorno. P. ej:
1. Dirección de func_oculta () = 0x08005f32
2. Ret-Buff = 32
$ perl -e 'print "\x90"x32 . "\x32\x5f\x00\x08"'

Hey Iván! Que tal? ;)

pianista

Pero me refiero:

La dirección que escoge el compilador, es una dirección que al final en memoria no va a ser esa, si no que va a ser totalmente diferente, dependerá de la memoria libre etc etc etc.

Mi duda es, puesto que el SO al final abstrae la memoria para el programa de manera que el cree que tiene toda la memoria del mundo, aunque en realidad tenga sus cachitos en cada cacho de memoria y no se corresponda con sus direcciones, al final las direcciones del compilador son las que usa en esa memoria virtual???

Respecto a lo de ejecutarlo es algo que te iba a preguntar, yo lo ejecuto a pelo, pero a lo mejor es que debería ejecutarlo en el gdb xD


printf "AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDD\xed\x83\x04\x08"|./overflow
Sale:
AAAAAAAAAABBBBBBBBBBCCCCCCCCCCDDDDDDí
Segmentation fault


Saludos y gracias!

Advertencia - mientras estabas escribiendo, una nueva respuesta fue publicada. Probablemente desees abandonar este campo y ir a cultivar campos de arroz

Lo de meter otra función lo probaré también.

Sagrini

Eso es que no has sobreescrito la dirección correcta. Corre desde GDB y mira el error que te da ;)
$ gdb -q code
(gdb) r $(perl -e 'print "..."')
...
(gdb)
Ponme la salida ;)

Ivanchuk

Cita de: Sagrini en 23 Diciembre 2011, 16:56 PM
Un último detalle sería decir que para comprobar si funciona correctamente, sería mejor declarar una función que no se llamase en el programa, y hacer que se ejecute con el retorno. P. ej:
1. Dirección de func_oculta () = 0x08005f32
2. Ret-Buff = 32
$ perl -e 'print "\x90"x32 . "\x32\x5f\x00\x08"'

Hey Iván! Que tal? ;)
Es una buena idea. Sagrini is back ! todo bien , vos?
Cita de: pianista en 23 Diciembre 2011, 16:57 PM
Pero me refiero:

La dirección que escoge el compilador, es una dirección que al final en memoria no va a ser esa, si no que va a ser totalmente diferente, dependerá de la memoria libre etc etc etc.

Mi duda es, puesto que el SO al final abstrae la memoria para el programa de manera que el cree que tiene toda la memoria del mundo, aunque en realidad tenga sus cachitos en cada cacho de memoria y no se corresponda con sus direcciones, al final las direcciones del compilador son las que usa en esa memoria virtual???
Al final lo unico que ves son las virtuales. Tendrias que correrlo en gdb y depurarlo con si para ver bien a donde vas a parar y si  sobreescribis bien el ret.
Sólo quien practica lo absurdo puede lograr lo imposible.

Join us @ http://foro.h-sec.org

pianista



Aquí os lo dejo la salida entera usando perl.

Ummm no creo que haya que usar la siguiente dirección, puesto que yo lo que quiero, es invocar dos veces a la misma función como indica el libro.

Gracias por vuestra ayuda, me está costando, pero es muy interesante el tema y más después de haber programado tanto en C hace años.

Saludos