ESTUDIO DEL SISTEMA ASLR

Estudio del sistema ASLR (Address Space Layout Randomization)

Marcelo Ortega

AbstractAddress Space Layout Randomization es una tecnolog a de seguridad que tiene como objetivo reducir las proba xito de un ataque que exija un conocimiento sobre bilidades de e la disposici on en memoria de las secciones de un programa. En este documento, se partir a de un breve estudio del funcionamiento de los distintos tipos de ataque por desbordamiento de buffer, para introducir la necesidad ante la cual surge el sistema ASLR, pasando as a estudiar su funcionamiento y actual implementaci on en el kernel de Linux en sistemas de 32 bits, para nalmente discutir sobre su ecacia y las formas de mejorarla.

I. I NTRODUCCI ON

OS lenguajes de programaci on que proporcionan herramientas de bajo nivel, como C y C ++, ofrecen al programador la posibilidad de un mayor control sobre el programa y recursos del sistema, pero como contrapartida hacen que los errores producto de distracciones y omisi on de detalles por parte de los desarrolladores, tengan un gran potencial da nino cuando son propensos a ser explotados por un atacante. As , cada l nea de c odigo puede ocultar una potencial amenaza a la seguridad de un sistema, dif cil de detectar y erradicar puesto que los grandes programas no son llevados a un tratamiento formal para asegurar su seguridad. Surge as la t ecnica del exploiting, la cual tiene su objetivo en encontrar una debilidad en el dise no o programaci on de un software, para poder manipularla a favor del atacante, xito modicando la l ogica de ejecuci on del programa. El e de esta t ecnica puede resultar en tres situaciones: el software v ctima termina su ejecuci on, lo que constituye un potencial ataque de negaci on de servicio; el software explotado altera su ujo de ejecuci on, permitiendo al atacante acceder a regiones de c odigo que no hubiera podido ejecutar de otra forma (por ejemplo por falta de permisos); o lo mas peligroso, el atacante logra ejecutar instrucciones ajenas al c odigo fuente original, pudiendo directamente ejecutar cualquier rutina, obteniendo el control total del sistema. ASLR surge como un m etodo no para erradicar por completo ninguna vulnerabilidad espec ca que pueda tener un sistema, sino como una forma de reducir las probabilidades de xito de cualquier tipo de ataque que exija un conocimiento e sobre la estructura y ubicaci on en memoria del programa. Todas las pruebas realizadas a lo largo de este documento se realizan sobre un sistema x86 virtualizado con kernel 3.4.6 y gcc 4.7.1. II. ATAQUES POR DESBORDAMIENTO DE BUFFER El espacio de memoria asignado a un proceso se divide en tres grandes zonas: Text, Data y Stack [Figura 1]. Text

Fig. 1.

Estructura de un programa en memoria

es la regi on ejecutable y solo de lectura donde se encuentra el c odigo del programa, las instrucciones de su ejecuci on. La regi on Data se puede descomponer en tres partes: Data, BSS y Heap. La primera es en donde se almacenan las variables globales y est aticas que son iniciadas asign andoles directamente un valor, mientras que aquellas a las que no se les asigna un valor inicial (solo se las declara) se encuentran en la segunda regi on, el segmento BSS. El heap comienza al nal del BSS y su tama no crece hacia direcciones de memoria superiores, mediante las llamadas al sistema brk() y sbrk(). En la regi on Stack es donde se encuentra el stack del proceso, lugar donde se almacenan para cada funci on en ejecuci on, sus par ametros de llamada, variables locales y direcci on de retorno. El tama no del stack es manejado por las instrucciones de PUSH y POP, creciendo en sentido contrario al heap, hacia direcciones de memoria inferiores, por lo que una vez que el tope del stack encuentre el n del heap, el espacio libre de memoria se habr a acabado, teniendo que interrumpir el programa. Cada vez que se llama a una funci on, la instrucci on CALL inserta en el tope del stack (push) el registro instruction pointer (IP), para que el ujo de ejecuci on del programa vuelva a ese punto una vez nalizada la rutina llamada. A este valor guardado del registro IP se le da el valor de RET. Por otra parte, el compilador tambi en guarda en el stack el registro EBP. Tambi en llamado frame pointer, este registro especica para cada funci on la direcci on en la cual comienza la regi on del stack que contiene sus variables locales y par ametros. Al contrario del registro SP, que apunta al tope del stack, y por lo tanto su valor cambia en cada PUSH y POP, el valor del ESP

ESTUDIO DEL SISTEMA ASLR

es jo dentro de cada funci on, haciendo que las las variables locales pueden ser referenciadas mediante su offset desde el EBP. Sup ongase entonces una funci on en la cual se declare un buffer de 25 bytes para alojar el input que le de el usuario, en el momento de su ejecuci on, el stack se ver a como indica la gura 2a. Al estar la direcci on de retorno contigua al n del buffer, si se provoca un desbordamiento de este, escribiendo mas all a de sus l mites, se podr a sustituir este RET por una direcci on de memoria arbitraria, a la cual el programa saltar a una vez nalizada la ejecuci on de la funci on actual, corrompiendo as el ujo de ejecuci on original. En un programa seguro, el tama no del contenido a ser escrito en el buffer no podr a nunca exceder su tama no, es decir, dada cualquier entrada, el programa solo copiar a 25 bytes en el buffer. Sin embargo, usualmente se utilizan funciones de la biblioteca de C que no hacen este tipo de control, sino que se limitan a copiar todo el contenido recibido hasta encontrar un byte nulo de n de l nea. Si bien existen funciones que solo copian una cantidad de bytes que el programador especique, como strncpy(), otras popularmente utilizadas como strcpy() no lo hacen, siendo susceptibles a ser v ctimas de un ataque por buffer overow. Volviendo al ejemplo anterior de buffer de 25 bytes, la gura 2b muestra en que estado quedar a el stack del programa si se le da el input AAA...(29 veces)..A\xF4\xF3\xF2\xF1. El valor de la direcci on de retorno queda entonces en 0xF1F2F3F41 . Por tratarse de una direcci on cualquiera, si no pertenece al espacio de memoria permitido para el proceso, cuando se vaya a realizar el retorno de la funci on se arrojar a un error segmentation fault. Pero el potencial de este ataque radica en que esta direcci on de memoria podr a ser cualquiera, ante lo que surgen diversas variantes, diferenciadas seg un a donde se redirige el ujo del programa. En cualquiera de los casos, el objetivo a perseguir ser a lograr obtener acceso a una shell del sistema, /bin/sh. A. Inserci on de c odigo en el stack El contenido que se inserta en el buffer puede ser cualquier conjunto de bytes, por lo que una t ecnica para explotar esto es insertar en el stack directamente en assembler el c odigo que se quiere ejecutar para acceder a la shell. Esta secuencia de instrucciones a insertar es llamada shellcode, y debe poder ser interpretada como un solo String, sin caracteres nulos antes de su nal. Se buscar a entonces redirigir el ujo del programa a donde se encuentra el c odigo insertado, para lo cual se deber a saber la direcci on de memoria del buffer y sobrescribir con ese valor el puntero RET. Es posible evitar la necesidad de conocer la direcci on exacta donde comienza el shellcode insertado si antes de este se escribe una gran secuencia de instrucciones NOP (NOP Sled). Esta instrucci on no realiza otra acci on que solo consumir ciclos de procesador, por lo que si se logra hacer que la direcci on RET apunte a alguna parte del NOP-Sled, los NOP se ejecutar an secuencialmente hasta que se terminen y se comience a ejecutar el shellcode introducido.
1 Por

(a) Estructura del Stack

(b) Buffer Overow

(c) NOP-Sled Fig. 2. Manipulando el stack

De todas formas es necesario saber en que regi on de memoria se encontrar a el buffer, de forma de tener posibilidades de acertar una direcci on de memoria dentro del NOP Sled. Se puede obtener esta informaci on sobre la estructura en memoria del programa usando un debugger como gdb. B. Retorno a c odigo del programa (ret2text) La regi on ejecutable donde se encuentra el c odigo del programa es de solo lectura, por lo que intentar insertar el rea acabar shellcode en esta a a en una violaci on de segmento. Sin embargo, es posible redirigir el ujo del programa a cualquier punto de esta regi on, sobrescribiendo RET con un puntero a esa direcci on de memoria dentro de Text. Esta t ecnica da lugar a dos grandes posibilidades, lograr el acceso a regiones del c odigo original que no son alcanzadas por el ujo de ejecuci on del programa en condiciones normales, o si no existen regiones as a las cuales sea interesante acceder, tambi en es posible encadenar distintas porciones til, como se del c odigo existente para formar un shellcode u describe en [10]. C. Retorno a Heap (ret2heap) Consiste en insertar el shellcode en una estructura del heap, para luego redireccionar el ujo del programa a esta regi on de memoria. Se sigue necesitando el input a un buffer en stack para poder hacer overow y sobrescribir RET, y adem as un nuevo input que permita introducir el shellcode en el heap.

tratarse de una arquitectura little-endian

ESTUDIO DEL SISTEMA ASLR

D. Retorno a librer a (ret2libc) La librer a est andar de C libc se linkea a todos los programas, por lo que sus funciones siempre se encuentran en el espacio de direccionamiento, haciendo posible sustituir el RET por un puntero a cualquier funci on de esta librer a. Determinando la direcci on de la funci on system()2 , se podr a insertar en el stack como par ametros los comandos que se quiere ejecutar, y redirigir el ujo a la funci on. Estas cuatro variantes de buffer overow comparten el mismo objetivo de desviar el ujo de ejecuci on sobrescribiendo el puntero RET con la direcci on conocida del shellcode que se quiere ejecutar. Otro caso de buffer overow puede ser si se busca sobrescribir datos que no sean punteros, es decir, una estructura de datos que se encuentre posterior al buffer. En este escenario, en vez de necesitar saber la direcci on de memoria del shellcode insertado, se tiene que tener conocimiento de la distancia relativa entre el buffer y la estructura a ser corrompida. III. A DDRESS S PACE L AYOUT R ANDOMIZATION Todas las variantes de buffer overow expuestas anteriormente exig an al atacante un profundo conocimiento del c odigo del programa v ctima, de sus organizaci on y sobretodo, de las posici on en memoria de sus distintas estructuras. La idea que persigue ASLR es reducir el conocimiento del atacante sobre el programa v ctima, haciendo que las direcciones virtuales de los distintos segmentos del programa, en vez de ser est aticas y siempre constantes, var en en cada ejecuci on aleatoriamente. xito de un ataque, ya Esto reduce las posibilidades de e que se necesitar an varios intentos para lograr determinar con seguridad en que ubicaciones est an dispuestas las estructuras xito corromper en memoria, y cada ataque sin e a el stack de una forma insostenible que forzar a el cierre del programa. Un xito en un sistema no tendr ataque que logre tener e a la misma suerte en otro, ya que las condiciones de ejecuci on variaran de una victima a otra, por lo que un mismo exploit no podr a ser xito en varios sistemas. A distribuido para tener e un m as, si el espacio de memoria virtual var a en cada ejecuci on, un mismo xito dos veces en un mismo sistema. ataque no tendr a e Si bien introducir un factor de aleatoriedad en la disposici on del programa en memoria no elimina las vulnerabilidades que se tenga, diculta que la explotaci on de estas tenga xito. A diferencia muchos m e etodos existentes que orientan la defensa contra casos espec cos de ataques conocidos, ASRL se presenta como un mecanismo general que act ua directamente contra los fundamentos en los que se basan una amplia cantidad de ataques. Existen dos grandes variantes de este mecanismo, diferenciadas seg un el momento en que se realiza la ubicaci on aleatoria: Tiempo de Compilaci on: El compilador es que implementa el mecanismo, resolviendo como asignar a el espacio de memoria virtual. No se debe realizar trabajo adicional en tiempo de ejecuci on, y se puede hacer que el posicionamiento var e en cada sistema si es el usuario
2 La funcion system() ejecuta comandos mediante la shell est andar (generalmente /bin/sh)

nal quien compila la aplicaci on. Tiene la gran desventaja que una vez compilado el programa las direcciones se mantendr an est aticas, por lo que una vez que el atacante determine la disposici on del programa, todos los ataques que realice ser an exitosos. Tiempo de Carga: El compilador genera c odigo independiente de la posici on, la cual se determina en tiempo de carga seg un la disposici on que se genere al azar. Si bien la traducci on de este c odigo trae un costo adicional, exhibe la ventaja de poder generar un layout de memoria diferente en cada ejecuci on que se haga.

N otese que hasta ahora no se determin o exactamente qu e es lo que ASLR determina aleatoriamente, qu e se considera la estructura en memoria del programa. En la secci on anterior se expusieron los diferentes segmentos que tiene el espacio de memoria de un proceso, dado que el funcionamiento del c odigo es independiente de sus posiciones, es decir, el stack funcionar a de igual forma est e en la posici on que est e, pero por el contrario, las direcciones en memoria si lo son, una forma de introducir el factor de entrop a buscado es aleatorizar las direcciones de comienzo de cada segmento. Este mecanismo no exige ning un requerimiento adicional, nico costo sera la perdida de utilidad que algunas regiones su u de memoria virtual tendr an debido a la fragmentaci on externa entre los segmentos. Dados los cuatro tipos de ataques mencionados en la secci on anterior, es de especial inter es generar al azar las direcciones de comienzo de los segmentos de Stack, Heap, Text y las direcciones de memoria en donde se mapeen las librer as linkeadas din amicamente. De esta forma se logra que las direcciones absolutas de un proceso no sean est aticas, y los ataques antes vistos perder an eciencia. Sin embargo, las distancias relativas entre objetos de un mismo segmento siguen inalteradas, un exploit que tenga como objetivo corromper datos del programa sin necesitar alterar el ujo de ejecuci on no se ver a afectado por este mecanismo. Con el objetivo de generar un factor de aleatoriedad en las distancias entre objetos, [5] presenta y propone una implementaci on a dos t ecnicas con las cuales complementar la aleatoriedad de los segmentos:

Permutaciones en el orden de variables y rutinas: Se puede permutar el orden de variables locales en un frame del stack, variables denidas est aticas y rutinas, tanto en el ejecutable principal como en librer as compartidas. Introducir espacios aleatorios entre objetos: Con el n de hacer variable la distancia entre los objetos que no son comprendidos en el punto anterior debido a su naturaleza (no es posible alterar el orden de bloques obtenidos mediante malloc, por ejemplo), se propone insertar espacios de un largo aleatorio entre estos objetos: stack frames, rea est llamadas sucesivas a malloc, variables en el a atica y rutinas.

Si bien estos mecanismos aumentan considerablemente la seguridad del programa, se debe tener un especial cuidado en no realizar modicaciones accidentales al c odigo del programa, teniendo en cuenta saltos indirectos, resoluci on de direcciones

ESTUDIO DEL SISTEMA ASLR

en el stack, etc. Para poder asegurar esto, se debe tener un grafo de los posibles ujos de ejecuci on del programa, lo cual diculta su implementaci on. Ahora bien, cuanto diculta ASLR la tarea del atacante? En el primer mecanismo presentado, esto depender a de la cantidad de bytes que se generen aleatoriamente para la base de los segmentos. Sea N la cantidad de bits que se generan al azar. Si el espacio de direcciones es generado nuevamente en cada ejecuci on, el numero de intentos esperados para que un atacante tenga xito adivinando la disposici e on en memoria se podria modelar como un problema de extracci on con reposici on. La variable aleatoria que seguir a esta distribuci on geometrica ser a 1 (1) p= N 2 Por lo que el n umero esperado de intentos es 1 = 2N (2) p Si por el contrario, el espacio de direcciones permanece constante a lo largo de los intentos, la probabilidad de que el xito en exactamente t intentos se calcula: ataque tenga e 2 t1 1 1 2 1 2 2 N N = N 2N 2 1 2N t 2 t1 2 Prob. primeros t-1 fallen (3) Entonces, el numero esperado de pruebas necesarias para tener xito es: e 1 1 2N + 1 t N = N t= 2N 1 2 2 2 t=1 t=1
2N 2N N N N

(a) Primera ejecuci on

(b) Segunda ejecuci on Fig. 3. Salida de /proc/pid/maps

(4)

En la gura 3 se muestra los mapas de memoria correspondientes a dos ejecuciones secuenciales del mismo programa. Las direcciones no son completamente aleatorias ya que se tiene algunas limitaciones a la hora de elegir la cantidad de bytes libres para la aleatoriedad:

IV. ASRL EN L INUX Originalmente, ASLR era parte del proyecto PAge eXec [11], un parche de seguridad en el cual fue implementado por primera vez en Junio del 2001. Desde la publicaci on del kernel 2.6.12 en Junio del 2005, ASLR esta implementado y activado por defecto en todos los n ucleos posteriores. El estado de funcionamiento de ASLR se puede comprobar en el archivo /proc/sys/kernel/randomize va space, tiene tres posibles valores: 0: Desactivado, las direcciones de memoria virtual de los segmentos ser an est aticas. 1: Hace aleatorias las direcciones de Stack, las de las p aginas mapeadas mediante mmap() (Por lo que las librer as compartidas ser an cargadas en direcciones aleatorias) y las de vDSO3 . 2: Habilita la generaci on aleatoria de la direcci on base del heap, adicionalmente a todo lo ofrecido con la opci on 1. Debido a que algunas aplicaciones preexistentes asumen rea de heap empieza justo despu que el a es del segmento Text y no pueden ejecutar correctamente bajo un heap til ofrecer al usuario la posibilidad de aleatorio, resulta u desactivar este aspecto.
3 Virtual Dynamically linked Shared Objects, un m etodo de hacer accesibles a rutinas del kernel desde el espacio de usuario, funcionan como system calls de acceso barato, ya que no es necesario el cambio de contexto [12]

Para facilitar el manejo y rendimiento del cach e, los segmentos deber an estar alineados al tama no de p agina en memoria virtual. Como las p aginas son de 4Kbytes, los ocho bits menos signicativos del comienzo de cada segmentos son nulos. Si el resultado del sorteo de las direcciones base hace que los segmentos colisionen, entonces habr a que repetir hasta el proceso hasta que se tenga una distribuci on que permita el funcionamiento normal del programa. Para evitar la p erdida de performance que conllevar a realizarlo repetidas veces, se debe regular la distancia m nima entre segmentos.

La aleatoriedad se introduce mediante la rutina get random int(), que genera un n umero al azar. La direcci on base del stack se asigna de la siguiente forma: Stack = DirBase (random() & 0x7FF) << 12b (5) Donde DirBase corresponde a la direcci on que se le asignar a al stack si estuviera ASLR desactivado, la direcci on de comienzo de p agina mas alta posible 0xBFFDF000. Se enmascara el n umero aleatorio con 0x7FF y se desplaza el resultado 12bits, para hacerlo coincidir con el paginado. Se introduce entonces un factor de aleatoriedad de 11 bits, debido a la mascara 0x7FF. El espacio del heap, asignado mediante la system call brk(),

ESTUDIO DEL SISTEMA ASLR

Cabe destacar la importancia en la suma del t ermino rdtsc. Un proceso puede conocer su PID, y el valor de jifes es constante dentro de un cierto intervalo de tiempo determinado por la frecuencia de la interrupci on del timer del sistema (seg un el valor de la constante del kernel HZ).[13] muestra una debilidad que se ten a en versiones anteriores donde no se sumaba rdtsc, en la que el atacante con un ataque de fuerza bruta logra obtener el PID y jifes buscados para conocer la semilla y predecir la salida de get random int() mediante la cual se generar a todo el layout de memoria del proceso. Al sumar tambi en rdtsc se introduce una granularidad m nima que hace que el cambio de semilla sea continuo desde la vista de un proceso, haciendo imposible su predeterminaci on. V. E FECTIVIDAD DE ASLR La implementaci on de ASLR en Linux logra introducir al atacante una dicultad a la hora de llevar a cabo un exploit en el que deba saber la direcci on de memoria de un objeto en stack, heap o cargado mediante mmap(). As , los ataques anteriormente presentados de inserci on de c odigo en el stack, xito si logran acertar en que ret2heap y ret2libc solo tendr an e posici on se encuentra el shellcode insertado. En el c alculo de la direcci on base del stack se introducen 13 bits de entrop a lo cual, aplicando la f ormula 2, da un xito en un promedio de 2048 intentos necesarios para tener e ataque por fuerza bruta. Realizando el c alculo para la regi on del heap y la asignada a las librer as, se tienen 4096 y 512 combinaciones posibles respectivamente. Dado que un proceso hijo resultado de fork() comparte la misma estructura de memoria virtual que el padre, en programas en los que se atiende a cada cliente con un nuevo proceso (por ejemplo, un servidor web que crea un nuevo hilo para cada solicitud) el promedio de intentos necesarios para xito en un ataque por fuerza bruta se ven a tener e un mas disminuidos a la mitad. As , en un ataque ret2libc realizado a un programa con estas caracter sticas solo ser an necesarios 256 intentos en promedio. Si bien el n umero de bits aleatorios esta limitado a la arquitectura, la implementaci on que Linx hace de ASLR en x86 parece bastante conservadora en comparaci on a por ejemplo, el parche de seguridad PaX que deja 24 bits aleatorios para la direcci on base del stack. Por otra parte, Linux deja completamente apartado de ASLR al segmento .text. En la salidas de /maps mostradas en la gura 3 se ve como la direcci on que se le asigna a las instrucciones de ejecuci on son siempre constantes. Un ataque ret2text no se ver a afectado, cualquiera sea el estado de activaci on de ASLR en el sistema. Tampoco hay que olvidar que Linux hace posible la lectura de la distribuci on de memoria de cualquier proceso a trav es del archivo especial /proc/pid/maps. Si bien un atacante remoto no deber a tener la posiblidad de acceder a este archivo, en las versiones 2.6.12 hasta 2.6.21, no eran necesarios permisos especiales para leer este archivo, permitiendo que el atacante local conociera sin problemas la disposici on en memoria del proceso, siendo nula la utilidad de ASLR. En las pr oximas versiones, la lectura del mapa de memoria solo es permitida

Fig. 4.

Ubicaci on base en mmap() seg un MAX GAP y MIN GAP

se dene: StartBrk = BrkBase (6)

+((random() % 0x02000000) << 12bits) El valor del numero aleatorio esta acotado por el m odulo con 0x02000000 y el desplazamiento de 12bits de alineamiento a p agina, por lo que puede tomar valores en el rango de 0 0x02000, 13 bits de aleatoriedad. rea asignada mediante mmap() debe tenerse especial En el a cuidado de evitar colisiones con el Stack, por lo que su direcci on base se calcula con el m aximo de tama no de memoria que tiene a un disponible el proceso (rlimit) y de forma de guardar una distancia preventiva con el m aximo tama no que puede tomar el stack (MIN GAP): Gap = min(max(M IN GAP, rlimit), M AX GAP ) (7) Donde MAX GAP corresponde a la direcci on m nima en la que puede estar asignada la base. La direcci on base se calcula entonces: M apBase= T ASK SIZE Gap (random() % (1 << 8bits)) (8)

La funci on get random int() se reserva exclusivamente para uso interno del kernel, y calcula una palabra al azar a partir de una suma de tres variables: El PID del proceso ejecut andose actualmente en el procesador que realiza la llamada La variable del sistema jifes Si la arquitectura lo soporta, el numero de ciclos de ltima inicializaci la CPU desde su u on, retornado por la instrucci on rdtsc El resultado de la funci on es una transformaci on MD4 de esta suma, de forma que un peque no cambio en alg un termino (por ejemplo, un incremento de jifes) resultar a en un valor aleatorio generado completamente distinto.

ESTUDIO DEL SISTEMA ASLR

para los procesos que el usuario posee, devolviendo una salida nula si ese no es el caso.

VI. V ULNERABILIDADES DE ASLR EN L INUX Por lo visto hasta ahora, la implementaci on de ASLR en Linux deja abierta la puerta al atacante a trav es de dos debilidades: la poca entrop a en las direcciones bases posibles para los segmentos, y la disposici on siempre constante del segmento .text. Puede ser que no sea interesante para el atacante la posibilidad de saltar el ujo de ejecuci on a alg un punto en particular del programa, pero el conocimiento del binario y de la disposici on de este en memoria le dan el poder de poder ejecutar cualquier instrucci on que se encuentre en este segmento. Las siguientes son dos de las t ecnicas de buffer overow presentadas por [15], denominadas Stack juggling Methods, y que logran evadir la protecci on ASLR mediante los aspectos reci en mencionados:

Fig. 5. ret2esp: La direcci on de retorno RET se sustituye por la de una instrucci on jump esp dentro de .text. Se salta entonces a lo apuntado por el registro ESP, donde se encuentra el shellcode.

B. Retorno a EAX (ret2eax) El valor que retorna cada funci on se guarda en el registro EAX, de forma que puede ser usado por la funcion que realiz o la llamada para por ejemplo, almacenarlo en un variable. Aunque es un aspecto poco conocido debido a que no tiene gran utilidad, la funci on strcpy retorna un puntero a el buffer en donde se copi o el contenido. Por lo si se realiza una llamda del estilo: bufptr = strcpy(buf,str); Provocar a que bufptr apunte a la misma direcci on de memoria que buf. Se almacene o no en una variable, strcpy siempre cargar a este puntero en el registro EAX. Lo mismo se cumple para otras funciones de manejo de strings. Por lo que si el programa realiza una copia del input a otro buffer, el EAX sera un perfecto puntero al shellcode insertado. En estos casos, para lograr saltar la ejecuci on al shellcode, basta con proceder de la misma forma que en ret2esp, pero en este caso sobreescribiendo RET por una direcci on de memoria en la que se encuentre la instrucci on call *%eax. Para que el registro EAX no sea alterado antes de ejecutada ltima funci la instrucci on ret, strcpy debe ser la u on que se llame en su rutina. De otra forma, el puntero al buffer que srtcpy dej o en el EAX ser a sobrescrito por cualquier otro contenido y el exploit no funcionar a. Al igual que para el caso de ret2esp, la direcci on de memoria de una instrucci on call *%eax puede ser encontrada por su opcode 0xffd0 el binario del programa, y al ser el segmento .text est atico, determinada en el espacio de memoria del proceso en el momento del exploit. VII. M EJORAS NECESARIAS EN FUTURAS IMPLEMENTACIONES DE ASLR Las vulnerabilidades mostradas se basan en la posibilidad de determinar la direcci on virtual a la que se mapear a el binario ejecutado. Si, al igual que el stack y el heap, la ubicaci on del segmento .text se determinara al azar, estos ataques no ser an aplicables. Por lo tanto, las regiones .Text, .Data y .BSS (que tampoco son aleatorias) deber an someterse al mismo procedimiento de aleatoriedad que los otros segmentos. Por otra parte, con el n de brindarle al sistema m as fortaleza contra ataques por fuerza bruta, es necesario que m as

A. Retorno a ESP (ret2esp) Al terminar una rutina se explusa del stack todas las variables locales que esta haya utilizado mediante la instrucci on leave, la cual igualar a el puntero de tope de pila ESP al stack frame EBP. Realizado esto, se recupera del stack el EBP de la funci on a la cual se retorna el control y el puntero a la siguiente instrucci on a ejecutar para volver al hilo de ejecuci on anterior. En un ataque de bufferoverow, en este punto se tiene el ESP apuntando a un lugar del NOP-Sled, pero se tiene un problema: el hilo de ejecuci on seguir a en la direcci on RET (en la gura 5 EIP) que por culpa del overow fue sobrescrito. Lo ideal ser a lograr que este apunte a la direcci on de comienzo del shellscript, pero ASLR impide esto ocultando en que direcci on de memoria esta ubicado el stack. Sin embargo si se pudiera realizar un salto al ESP, se ejecutar a el NOP-Sled xito. hasta llegar a el shellcode introducido y el ataque tendr a e Lo que se necesita entonces es conocer alguna direcci on de memoria en la que se encuentra una instrucci on jump *%esp, y sobreescribir con este valor el puntero RET. La t ecnica entonces consiste en buscar en el binario del programa esta instrucci on, ya que al ser el segemento .text est atico, se podr a determinar su ubicaci on en el espacio de memoria virtual del proceso. Si bien la instrucci on jmp *%esp no es producida por gcc por cuestiones de seguridad, se la puede generar articialmente si se busca en el binario cualquier direcci on de memoria que contenga su opcode, e4ff. Saltando a esta direcci on, el CPU interpretar a el contenido como una instrucci on de salto a la direcci on de memoria apuntada por el registro ESP, y el xito. Cuanto m ataque hab ra tenido e as grande sea el binario del programa v ctima mas posibilidades de encontrar el e4ff buscado entre todo el c odigo, pudiendose dar por ejemplo el caso de que se utilice una constante de este valor, 58623 en decimal.

ESTUDIO DEL SISTEMA ASLR

bits de las direcciones base de los segmentos sean generados aleatoriamente. El alineamiento con el tama no de p agina siempre ser a necesario para facilitar el manejo de memoria y tener una mejor eciencia de cach e, de ahi la necesidad ltimos 12 bits. De los 20 bits restantes, de dejar est aticos los u algunos de los mas signicativos deben ser est aticos para evitar colisiones y fragmentaci on entre segmentos. El problema de la implementaci on de ASLR en Linux es que esta cantidad es excesiva y desperdicia una potencial capacidad de generar mas entrop a. El sistema PAX deja solo los primeros 4 bits mas signicativos jos, pudiendo asi generar aleatoriamente 16 bits para cada segmento. La efectividad de ASLR encuentra un gran salto en arquitecturas de 64bits, en donde m as bits pueden ser aleatorios, d andole un considerable incremento a la entrop a. Suponiendo que el tama no de p agina sigue siendo de 4Kb (en arquitecturas de este tipo se lo podr a incrementar a 4Mb), y que se dejan est aticos los 4 bits m as signicativos, se tienen en total 48 bits de entrop a posibles. Aplicando la f ormula 2, se tiene una cantidad de combinaciones posibles de 2 elevado a la 48, una cantidad que excede por lejos el alcance de cualquier ataque por fuerza bruta que se quiera realizar. No obstante, [14] logra, apoyando el ataque por fuerza bruta en otras condiciones de inseguridad que se podr an cumplir en el programa, reducir considerablemente la cantidad de intentos necesarios y lograr xito en una cantidad de iteraciones posible. e Sin embargo, Linux no aprovecha las posibilidades que los 64 bits ofrecen a ASLR. En la gura 6 se ve como el no repartir los segmentos por todo el espacio de direcciones disponible reduce el rango de direcciones aleatorias asignables. En el caso del stack, solo se tiene una entrop a de 20 bits, que si bien es mejor a la de x86, esta muy lejos de explotar todas las posibilidades que x86 64 ofrece. Tampoco se debe sacar importancia al generador de n umeros aleatorios, que es en denitiva la piedra fundamental de ASLR. Con la implementaci on actual, no puede decirse que los n umeros generados sean aleatorios sino pseudo-aleatorios ya que su semilla esta denida determin sticamente: puede ser dif cil adivinar el valor exacto que retorna la instrucci on rdtsc, pero al ser un contador de tiempo, su valor aumenta linealmente, se puede acotar en un intervalo determinado si se conoce una estimaci on de su valor inicial. Una gran mejora en este aspecto aporta la microarquitectura de procesadores Intel Ivy Bridge, que introduce la utilizaci on de una nueva unidad de hardware para generar n umeros aleatorios, usando como fuente de entrop a el ruido t ermico de los transitores. Mediante la nueva instrucci on rdrand, se genera un n umero completamente aleatorio para el cual no existe estado inicial que pueda ser conocido para predecirlo. Si bien hoy en d a no hay vulnerabilidades conocidas que exploten la mala calidad de los n umeros aleatorios generados por el kernel, los procesadores Intel que soportan esta instrucci on son cada vez mas utilizados en computadoras de escritorio, haciendo interesante su utilizaci on en pr oximas versiones del kernel. VIII. C ONCLUSIONES Se han mostrado que tipos de ataques previene ASLR, y cuales son su debilidades actuales que hacen que otras t ecnicas

(a) Primera ejecuci on

(b) Segunda ejecuci on Fig. 6. Salida de /proc/pid/maps en una arquitectura x86 64, Fedora 17 Kernel 3.4.6-2

xito. Linux puede y debe mejorar de exploiting sigan teniendo e en pr oximas versiones su t ecnica de implementaci on de ASLR, siendo los principales dos pasos a seguir abarcar tambi en al sector Text y utilizar mas bits en la entrop a de arquitecturas de 64 bits, cada vez mas utilizadas y accesibles. Sin embargo, por m as que se implementen estas mejoras, los ataques por fuerza bruta ser an posibles y, al menos en 32 bits, xito en una cantidad razonable de intentos. lograr an tener e [3] logra vulnerar ASLR en un ataque mediante un ataque de este tipo en un tiempo promedio de 216 segundos, para una entrop a de 16 bits. Cada intento fallido de un ataque de fuerza bruta generar a una violaci on de segmento que abortar a el proceso v ctima. El atacante simplemente abrir a otro (por ejemplo una nueva conexi on http si el objetivo es un servidor xito. Web) e intentar a nuevamente hasta tener e Se tiene entonces una gran limitaci on en la utilidad que ASLR pueda aportar directamente a la seguridad de un sistema. Por esto se recomienda que su utilizaci on se acompa ne con la de otros mecanismos de seguridad: Extensiones de compilador: Estos mecanismos insertan en el stack un n umero aleatorio elegido al comienzo del programa llamado canary value entre la direcci on de retorno y las variables locales. Al retornar de una funci on se verica que su valor no haya sido modicado con respecto al elegido en la iniciaci on. Cualquier ataque por buffer overow sobrescribir a el canary value incorrectamente, por no saber que n umero aleatorio fue elegido, y acabar a siendo detectado. Algunas implementaciones de

ESTUDIO DEL SISTEMA ASLR

este mecanismo son StackGuard y StackShield. Librer as envueltas: Gran parte de las vulnerabilidades que los ataques por buffer overow explotaban eran causadas por un mal uso de algunas funciones inseguras de C. La idea de librer as como LibSafe y FormatGuard es interceptar las llamadas a estas funciones y manejarlas de forma correcta. Stack no ejecutable: Todos los ataques por inserci on de c odigo inyectan el c odigo en segmentos de datos como el stack y el heap, para luego lograr saltar el control del programa a ese punto. Si estos segmentos no tuvieran permisos de ejecuci on, el atacante no tendr a forma de ejecutar el shellcode insertado, a la vez que el programa no se ver a afectado

Si bien ninguna de estas t ecnicas es infalible por si sola, su potencialidad se encuentra en combinar varias de ellas en un mismo sistema. Que eciencia tiene entonces ASLR? Mucha, dando una buena medida de protecci on a un buen costo, teniendo un impacto casi nulo en la performance del sistema. Cual es la ecacia de ASLR? Poca si no se combina con otras herramientas. En particular, es de inter es apoyar ASLR con un sistema de detecci on y reacci on ante los intentos fallidos que tendr a cualquier ataque por fuerza bruta cuando cause violaciones de segmento y aborte el proceso. Interesa contar un mecanismo que detecte estas violaciones y pueda tomar una acci on para xito. impedir al atacante llegar a tener e Hay que valorar entonces a ASLR como una herramienta mas para brindar seguridad contra ataques que exploten las fallas de programaci on, pero nunca hay que conar en que esta (ni cualquier otra) herramienta garantizar a la seguridad completa del sistema. Entonces, los programadores deben prestar especial atenci on a la construcci on que le dan a sus programas, siendo necesario someterlos a un estricto an alisis en busca de esas vulnerabilidades que escapan a los ojos f acilmente pero que esconden una gran amenaza a la seguridad. Amenaza que ASLR podr a mitigar, pero jam as erradicar por completo. A PPENDIX DE ASLR EN OTROS S ISTEMAS I MPLEMENTACI ON O PERATIVOS A. ASLR en Windows Windows implementa ASLR desde su versi on Windows Vista lanzada en el 2006. Para que un ejecutable, como ser un binario (.exe) o una librer a din amica (.dll) participe en ASLR debe activar el bit de control correspondiente (0x40) en su cabecera PE (Portable Executable, un formato de archivo ejecutable similar a ELF). Cuando se carga una imagen que haya elegido participar de ASLR, se le aplica a la direcci on en memoria de su ejecutable un desplazamiento aleatorio respecto a su direcci on de preferencia. Este desplazamiento se genera al azar en cada inicializaci on del sistema y es global a todos sus procesos. De esta manera, un DLL que sea compartido entre varios procesos se cargar a para todos en la misma direcci on de memoria, ya que el offset aleatorio sera para todos igual.

La disposici on de los segmentos de datos se realiza primero determinando la posici on del stack para luego en base a esto asignar un lugar al heap. Para la direcci on del stack se selecciona una regi on de 32 posibles, y se la desplaza aleatoriamente, dando as en 16.384 posibles valores para su ubicaci on en una arquitectura x86. Para la determinar la regi on del heap se aplica un procedimiento especial, cuidando evitar posibles colisiones con el stack. Un estudio realizado por Symantec [7], demuestra que en este sistema de implementaci on en Windows Vista exist a una distribuci on no uniforme que hac a que en la pr actica, solo un peque no rango de direcciones base fueran realmente utilizadas, frente a las miles que deber an ser posibles te oricamente. La nueva versi on Windows 8 mejora algunos aspectos de reas del espacio de direcciones su sistema ASLR. Nuevas a virtuales entran en ASLR, y se a nade una mejora signicativa en la entrop a, explotando la potencialidad de las arquitecturas de 64 bis. Una debilidad de Windows Vista era que por m as que un programa fuera compilado eligiendo participar de ASLR, el agregado de componentes desarrollados por terceros (por ejemplo un plugin para un navegador web) que no hubiera habilitado ASLR resultaba en una porci on del espacio virtual no aleatorizada, una potencial vulnerabilidad a ser explotada por el atacante. En respuesta a esto, Windows 8 a nade la opci on ForceASLR, que obliga a todos los m odulos inyectados a un proceso a participar en ASLR, independientemente de su elecci on particular. B. ASLR en iOS ASLR esta disponible en iOS desde su versi on 4.3, lanzada en el 2011. Se dispone de dos niveles de ASLR, uno limitado y otro extendido, dependiendo de si la aplicaci on fue compilada usando c odigo independiente de posici on (PIE4 ) o no. En el modo limitado, los unicos segmentos cuya base se determinar a aleatoriamente ser an el heap y las librer as din amicas. Si la aplicaci on tiene soporte PIE, podr a hacer uso completo de ASLR, y todos los segmentos ser an aleatorios. En la versi on 6 de iOS, Apple a nade el mecanismo Kernel Address Space Layout Randomization (KASLR), con el n de mejorar la seguridad de la plataforma contra los ataques jailbreak, que buscan eliminar las restricciones que el fabricante impone en sus dispositivos (por ejemplo, descargar nicamente a trav aplicaciones u es del App Store). Mediante KASLR, la regi on en memoria del kernel es determinada aleatoriamente al iniciar el sistema impidiendo que un exploit xito asegurado. la modique con e R EFERENCES
AT [1] H. Kopka and P. W. Daly, A Guide to L EX, 3rd ed. Harlow, England: Addison-Wesley, 1999. [2] Aleph One. Smashing the stack for fun and prot. Phrack Magazine, 49 (14), Nov 1996. http://www.phrack.com/issues.html?issue=49&id=14 [3] Hovav Shacham, Matthew Page, Ben Pfaff, Eu-Jin Goh, Nagendra Modadugu and Dan Boneh. On the Effectiveness of Address-Space Randomization, Oct 2004. http://stanford.edu/blp/papers/asrandom.pdf 4 Position

Independent Executables

ESTUDIO DEL SISTEMA ASLR

[4] Tilo M uller, ASLR Smack & Laugh Reference. Seminar on Advanced Exploitation Techniques, Feb 2008. http://www.cs.umd.edu/jkatz/security/ downloads/ASLR.pdf [5] Sandeep Bhatkar, Daniel C. DuVarney and R. Sekar. Address Obfuscation: an Efcient Approach to Combat a Broad Range of Memory Error Exploits. http://seclab.cs.stonybrook.edu/seclab/pubs/usenix03.pdf [6] Dirk Gordon, Address Space Layout Randomization Department of Computer Science and Software Engineering University of WisconsinPlatteville http://www.uwplatt.edu/csse/courses/prev/csse411-materials/ f09/Dirk%20Gordon%20-%20Seminar%20Paper%20Fall%2009%20-% 20ASLR.doc [7] Ollie Whitehouse, An Analysis of Address Space Layout Randomization on Windows Vista. Symantec Advanced Threat Research http://www.symantec.com/avcenter/reference/Address Space Layout Randomization.pdf [8] vlan7, Bypassing local Linux x86 ASLR protection. ASM / Shellcoding Series II, 2011 http://www.overowedminds.net/Papers/vlan7/0x04 bypassing local Linux x86 ASLR protection revisited.pdf [9] Albert L opez Fern andez, Introducci on a la explotaci on de software en sistemas Linux. 2009 http://www.overowedminds.net/Papers/newlog/ Introduccion-Explotacion-Software-Linux.pdf [10] Sebastian Krahmer, x86 64 buffer overow exploits and the borrowed code chunks exploitation technique, 2005 http://www.suse.de/krahmer/ no-nx.pdf [11] PaX, http://pax.grsecurity.net/ [12] Matt Davis, Creating a vDSO: the Colonels Other Chicken Linux Journal, 2012 http://www.linuxjournal.com/content/ creating-vdso-colonels-other-chicken?page=0,1 [13] Hagen Fritsch, Bypassing ASLR by predicting a process randomization, 2009. http://www.blackhat.com/presentations/bh-europe-09/Fritsch/ Blackhat-Europe-2009-Fritsch-Bypassing-aslr-whitepaper.pdf [14] Christian W. Otterstad, Brute force bypassing of ASLR on 64-bit x86 GNU/Linux. Norwegian Information Security Conference, NISK 2012, 2012. http://www.tapironline.no/last-ned/1081 [15] Izik Kotler. Smack the Stack, 2005. http://web.textles.com/hacking/ smackthestack.txt [16] Greg Taylor, George Cox. Behind Intels New Random-Number Generator. IEEE Spectrum, 2011. http://spectrum.ieee.org/computing/hardware/ behind-intels-new-randomnumber-generator/0 [17] Microsoft Windows Support: Update for ASLR feature. http://support. microsoft.com/kb/2639308#aboutASLR [18] Dino A. Dai Zovi. Apple iOS 4 Security Evaluation Trail of Bits LLC. www.trailofbits.com/resources/ios4 security evaluation paper.pdf [19] Mark Dowd, Tarjei Mandt. iOS 6 Kernel Security: A Hackers Guide http://www.ruxconbreakpoint.com/assets/Uploads/bpx/D1T2% 20-%20Mark%20Dowd%20&%20Tarjei%20Mandt%20-%20iOS6% 20Security.pdf