return-to-libc no puede obtener la dirección de la función del sistema

Navega tus respuestas
2

Estoy tratando de explotar mi propio código, solo para aprender cómo funciona la técnica "return-to-libc".

Sigo un tutorial que básicamente dice que para usar esto, debo encontrar la dirección de la función que quiero usar.

Para permanecer en el clásico, elijo usar la función "sistema" para obtener un shell.

Mis pasos para encontrar esta dirección son:

  1. ejecuta gdb con como argumento el nombre del ejecutable que quiero explotar. p.ej. "$ gdb test"
  2. coloque un punto de interrupción para detener el código cargado. Digamos "b main" en el indicador de gdb
  3. ejecuta el código que se detiene en el punto de interrupción "r"
  4. obtener la dirección con "p system"

Este es un ejemplo de lo que hice: 

GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".<br>

(gdb) b main
Breakpoint 1 at 0x8048468
(gdb) r
Starting program: /home/ale/test

Breakpoint 1, 0x08048468 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} **0x2779b0** <system>
(gdb) q


GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) b main
Breakpoint 1 at 0x8048468
(gdb) r
Starting program: /home/ale/test

Breakpoint 1, 0x08048468 in main ()
(gdb) p system
$1 = {<text variable, no debug info>} **0x1459b0** <system>

Parece que cada vez que inicio gdb obtengo una dirección diferente? ¿Puede alguien explicarme por qué?

¿Es esta una función de mitigación incorporada en mi kernel / linux hecha para evitar el uso de esta técnica de explotación?

Más tarde, buscando en Google, finalmente encontré algo que se ajusta un poco a mi situación. Parece que existe una función llamada " aleatorización del diseño del espacio de direcciones del kernel " que es similar en algunos aspectos a lo que yo Estoy experimentando. Sin embargo, si entiendo completamente lo que es esta asignación aleatoria de diseño de espacio de direcciones del Kernel, debería experimentar este beaviour una vez cada vez que recargo el kernel, en cambio, tengo este comportamiento cada vez que comienzo el código a través de gdb. De hecho, al construir el siguiente código simple, el comportamiento extraño experimentado no parece estar allí: 

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

int main()
{
 printf("%p\n", (void*)system);
}

Este código debe mostrar la dirección de la función system (). Probándolo, produce cada vez la misma dirección. Parece que este extraño comportamiento está relacionado con el gdb, pero no estoy seguro ... Estoy confundido.

    
pregunta alessandro 29.04.2016 - 17:18
fuente

1 respuesta

1

Parece que encontré una respuesta, al menos una especie de.
Bueno, como sospechaba, los desarrolladores del kernel están muy lejos de mí.
De hecho, la " aleatorización del diseño del espacio de direcciones " parece producir el comportamiento que observé en mi sistema.
Cuando leí el artículo de wikipedia, entendí que el espacio de direcciones está estructurado una vez cada vez que se inicia el kernel, pero al probarlo, verifiqué que en realidad las cosas son ligeramente diferentes. GDB tiene una característica excelente llamada " deshabilitar aleatorización " que está activada de forma predeterminada.
A pesar de eso, libc system (), y supongo que cualquier función libc, cambia su dirección cada vez que inicio GDB.
Al profundizar, encontré que la función del kernel puede estar deshabilitada en el nivel del kernel a través de " / proc / sys / kernel / randomize_va_space ".
Mi kernel por defecto estaba configurado en el valor 2.
Poniéndolo en 0, me di cuenta de que la aleatorización se detiene.
Todo parece claro ahora, pero todavía hay una pieza que no encaja.

  • Por qué el código que escribí para imprimir la dirección del sistema libc, cuando lo ejecuto a partir de la solicitud produce en cualquier momento la misma dirección?
  • Es el código que escribí, que no solicita la función que produce este resultado?

ACTUALIZACIÓN
si hay alguien lo suficientemente bueno, me gustaría que este tipo me explique esto: 

$ cat /proc/sys/kernel/randomize_va_space
0
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00110000)
        /lib/ld-linux.so.2 (0x00843000)
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00dcd000)
        /lib/ld-linux.so.2 (0x0037b000)
$ ldd /tmp/t
        libc.so.6 => /lib/tls/libc.so.6 (0x00ab7000)
        /lib/ld-linux.so.2 (0x00f14000)
    
respondido por el Alessandro 30.04.2016 - 12:36
fuente

Lea otras preguntas en las etiquetas

¿Qué es la autenticación basada en atributos? ¿Cuál es el propósito de los marcadores de posición (por ejemplo,% k,% f) en algunas opciones de GnuPG?