 Autor
|
Tema: Mi EIP no se machaca con AAAA's (Leído 3,898 veces)
|
Basurian
 Desconectado
Mensajes: 2
|
Buenas a todos, tengo un script muy simple para practicar y pronto me surgen dudas  : #include <string.h> #include <stdio.h> void func(char *arg) { char nombre[32]; printf("\nHas introducido: %s\n\n", nombre ); } int main(int argc, char *argv[]) { func(argv[1]); printf("Fin del programa\n\n"); return 0; }
y ejecutándolo con GDB para ver cuándo sobreescribo el EIP: (gdb) run AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTTUUUUVVVVWWWWXXXXYYYYZZZZ
Starting program: /home/basuri/prueba AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTTUUUUVVVVWWWWXXXXYYYYZZZZ
Bienvenido a Linux Exploiting AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTTUUUUVVVVWWWWXXXXYYYYZZZZ
Program received signal SIGSEGV, Segmentation fault.
0x0000000000400643 in func ()
(gdb)Según la práctica, debería obtener una respuesta del tipo: 0x4c4c4c4c in func ()Y no entiendo por qué me devuelve ese valor de memoria o por qué es tan largo. Estoy practicando en un Ubuntu 14.04 64 bit sobre un Mac OS X 64 bit. Estaría muy agradecido si alguien me echa una mano. Saludos a todos. |
|
|
|
|
En línea
|
|
|
|
|
.:UND3R:.
|
Estás compilando el ejecutable sin algún tipo de protección? Recuerda que al compilar se generan protecciones por defecto como cookies del stack, safe SEH entre otros, saludos.
|
|
|
|
|
En línea
|
 Solicitudes de crack, keygen, serial solo a través de mensajes privados (PM) |
|
|
x64core
Desconectado
Mensajes: 1.908
|
Estás compilando el ejecutable sin algún tipo de protección? Recuerda que al compilar se generan protecciones por defecto como cookies del stack, safe SEH entre otros, saludos.
¿Podes decirnos que tiene que ver con la pregunta? @Basurian: Deberias de revisar esas practicas ya que deberia de hablar acerca de qué configuraciónes se deberian pasar al compilador para que los ejecutables se generen como se espera. Para mi que practicando con programas generados desde lenguajes de alto nivel no es muy practico, ya que se esta suponiendo que se obtendrá un determinado código generado por el compilador. Compiladores son libres de generar el código como mejor convenga, dependiendo de las configuraciónes (debug, release, o alguna personalizada) generarán en la pila alineamientos, rellenos o incluso comprobadores para evitar eso mismo que estas haciendo. A pesar de las configuraciones algunos generan optimizaciónes donde el usuario nisiquiera es consiente de eso y muchas situaciónes como esas...
|
|
|
|
« Última modificación: 29 Noviembre 2014, 21:20 pm por x64Core »
|
En línea
|
|
|
|
|
dRak0
|
¿Podes decirnos que tiene que ver con la pregunta?
@Basurian:
Deberias de revisar esas practicas ya que deberia de hablar acerca de qué configuraciónes se deberian pasar al compilador para que los ejecutables se generen como se espera. Para mi que practicando con programas generados desde lenguajes de alto nivel no es muy practico, ya que se esta suponiendo que se obtendrá un determinado código generado por el compilador.
Compiladores son libres de generar el código como mejor convenga, dependiendo de las configuraciónes (debug, release, o alguna personalizada) generarán en la pila alineamientos, rellenos o incluso comprobadores para evitar eso mismo que estas haciendo. A pesar de las configuraciones algunos generan optimizaciónes donde el usuario nisiquiera es consiente de eso y muchas situaciónes como esas...
Tiene que ver; algunas versiones de gcc pone proteccion por defecto. Mira , desactiva aslr , y pasale como argumento a gcc fno-stack-protector. x64core tiene razon con el tema de los compiladores , lo que yo hago es poner un breakpoint en main y desensamblar la funcion donde esta la vulnerabilidad y fijarme cuanto espacio reservo para variables locales.
|
|
|
|
|
En línea
|
|
|
|
x64core
Desconectado
Mensajes: 1.908
|
Tiene que ver; algunas versiones de gcc pone proteccion por defecto.
Mira , desactiva aslr , y pasale como argumento a gcc fno-stack-protector.
x64core tiene razon con el tema de los compiladores , lo que yo hago es poner un breakpoint en main y desensamblar la funcion donde esta la vulnerabilidad y fijarme cuanto espacio reservo para variables locales.
El punto es que esto es claramente asunto de la pila, la gente de esas practicas deberia incluir los ejecutables con los que se trabajara, sino pues que programen en ensamblador y evitar este tipo de situaciones.
|
|
|
|
|
En línea
|
|
|
|
Basurian
Desconectado
Mensajes: 2
|
Gracias a todos por las respuestas,
el binario fue compilado con -fno-stack-protector y -z execstack. A la vez el fichero /proc/sys/kernel/randomize_va_space fue sobreescrito con valor 0.
Sin embargo, aún así, debe existir alguna medida de protección adicional que me impide sobreescribir el EIP. He probado con un Kali 1.0.9 de 64 bit y tampoco soy capaz. Sin embargo he probado un Ubuntu 12.04 (32 bits) y consigo el resultado esperado de sobreescribir con AAAAA's el EIP.
De paso sin embargo he comprendido que la diferencia de tener una dirección de memoria el doble de larga (16 caraceteres hexadecimales) se debe a que el sistema sea 64 bit. 16 caracteres hex x 8 bytes= 64 bits.
no obstante me gustaría saber qué demonios protege la sobreescritura del EIP en el Ubuntu 14.04 o el Kali 1.0.9. ¿Puede tener que ver que ambos sean 64 bit?
|
|
|
|
|
En línea
|
|
|
|
|
 |
