ASLR en Linux no aleatoriza bibliotecas por separado

5

Estaba probando cómo funciona ASLR en Centos 7.2.1115 x86_64 específicamente.

Aquí están mis volcados /proc/$pid/maps de dos ejecuciones de Firefox (en Pastebin): # 1 # 2

Básicamente, ASLR funciona. Aleatoriza las compensaciones .data y .text.

Sin embargo, contiene todas las bibliotecas y ejecutables en el mismo orden y sin espacios vacíos. (Bueno, en su mayoría. Hay variaciones de pareja, pero parecen puramente accidentales).

Entonces, tan pronto como se compromete la dirección única, toda esta parte de ASLR se sale de la ventana.

Mi pregunta es , ¿es el caso común a partir de ahora? ¿Qué sistemas abordan este problema y cómo?

Quiero decir, el espacio de direcciones de 64 bits es enorme , puedes lanzar aleatoriamente cada biblioteca y luego verificar si se superpone con algo, y colocarlo luego de un par de intentos. Sin embargo, la mejor solución ya implementada que encontré en Google es la aleatorización de órdenes de carga de bibliotecas en Android.

    
pregunta EvgEnZh 22.11.2016 - 11:58
fuente

1 respuesta

3
  

Sin embargo, contiene todas las bibliotecas y ejecutables en el mismo orden y sin espacios vacíos. Entonces, tan pronto como la dirección única se ve comprometida, toda esta parte de ASLR se sale de la ventana.

No del todo. ASLR aún trabaja para reducir las posibilidades de explotación ciega, ayudando a evitar que un atacante salte de manera confiable a un punto de ejecución. Si no conoce un punto en particular para sobrescribir, entonces su próxima táctica es NOP deslizar la memoria cercana de todos modos. Junto con la dirección de inicio que se asigna al azar, es muy probable que seleccione algo en el campo sin tierra como un código útil independientemente de la fragmentación.

  

Quiero decir, el espacio de direcciones de 64 bits es enorme, puedes lanzar aleatoriamente cada biblioteca y luego verificar si se superpone con algo, y colocarlo con éxito después de un par de intentos.

Es cierto, pero eso incurre en un problema de rendimiento. Cada entrada de aleatorización requerirá una entrada en el TLB , lo que resultará en una mayor utilización de recursos y más memoria desperdiciada / no utilizada debido a alineación de bloques.

  

Mi pregunta es, ¿es el caso común a partir de ahora? ¿Qué sistemas abordan este problema y cómo?

Por las razones mencionadas anteriormente, de hecho es el caso común. Comprender las limitaciones del ataque ayuda a comprender por qué el uso de los "bits de memoria en todas partes" más caros tiene un beneficio limitado.

Un punto de bonificación: la explotación más común es escribir demasiados datos en un bloque de datos y luego ejecutarlos. El bit NX también es una contramedida sustancial.

    
respondido por el Jeff Ferland 22.11.2016 - 20:43
fuente

Lea otras preguntas en las etiquetas