Buffer overflow: las direcciones en las que se apila siempre cambian (flag suid)

[Ethicalsk]

Hola informáticosl!!! Estaba tratando de seguir el clásico y básico ejercicio de buffer overflow sobre mi kali de 64 bits, éste ejercicio para ser concreto:

https://www.exploit-db.com/docs/33698.pdf

Pude explotarlo dentro de gdb como root (logrando imprimir el contenido de passwd) y luego probé con otra shellcode que ejecutaba bin dash que también funcionó (tuve la shell privilegiada).... La dirección de retorno que usaba siempre era la misma por más que abriera el programa en gdb una y otra vez... Luego probe lo mismo pero usando una consola no privilegiada y llegue a exactamente lo mismo, solo que obtuve una shell no privilegiada (hasta aqui todo normal)... El problema empezó cuando le di chmod +s bof (bof es el programa vulnerable). Entré en una shell no privilegiada, abri el gdb, busqué la dirección de memoria en la que se empezaba a apilar la shellcode y cuando reinicié el gdb para correr el programa (junto con el exploit con la dirección de retorno modificada) resulta que me tira segmentation fault... Recorrí paso por paso de vuelta y noté que cada vez que reiniciaba gdb, la shellcode se apilaba en direcciones de memoria distintas, lo cuál me imposibilitó en saber qué dirección usar como la de retorno.... Otra cosa: si quiero explotar el programa fuera del gdb, la shellcode se apila en diferentes direcciones sin importar si está activado o no el flag de suid... Me imagino que ustedes se toparon con algo de ésto... Sabrían alguna solución o método para saber que dirección de retorno usar, o alguna forma para que la shellcode se apile siempre en las mismas direcciones? Gracias desde ya!! Toda la información que necesitan para ayudarme con mi duda está en el pdf, yo seguí paso por paso de ahi... Es el ejemplo básico que encuentran en todos lados... Saludos!!!! 

[Ethicalsk]

La solución a mi problema:

echo 0 > /proc/sys/kernel/randomize_va_space

Moraleja: antes de preguntar algo averigüen un poco más jaja

[MagoAstral]

Bueno como ya te diste cuenta era todo por culpa de la ASLR, te recomendaría que leyeras cómo bypassearla bien con cadenas ROP, bien bruteforceando la dirección, etc...
https://www.exploit-db.com/docs/17914.pdf
Salu2

[Ethicalsk]

Muchas gracias por aportar!!!! Ahora mismo lo leo!