Si estoy en lo correcto, debido a ASLR cargamos libc en alguna dirección aleatoria. Y luego, para que esto suceda sin permitir permisos de escritura de páginas de texto dentro de la memoria, usamos plt / got. Ahora puedo simplemente saltar a alguna función libc @ plt que es bien conocida antes de la ejecución del programa y prácticamente omitirla. Entonces, ¿Return-to-plt hace inútil todo el concepto?
Sí, si PIE está deshabilitado. A menudo se dice que la efectividad de ASLR es reducido significativamente para aplicaciones que no están compiladas con el soporte PIE (Código independiente de la posición). Cuando no se usa PIE, el programa debe confiar en una PLT fijo , creado durante la vinculación, para resolver las direcciones de las funciones en bibliotecas compartidas. Cuando se usa ASLR y PIE está habilitado, los ataques de reutilización de código en general se mitigan, aunque las infracciones todavía son tan omnipresentes que ASLR a menudo puede ser derrotado con ataques de canal lateral , lo hace casi inútil contra el código malicioso local y limita su efectividad a los ataques en la red y exploits sin script . Hay varias otras razones por las que ASLR sin PIE es más débil y se usa menos asignación al azar, como se explica en en otra respuesta .
volver a plt y regresar a libc son ataques ligeramente diferentes.
Volver a libc
Una de las formas de evitar el desbordamiento del búfer es usar una pila no ejecutable. Para hacer una pila no ejecutable, desde CPU & A nivel de sistema usan algo llamado NX bit. Si se establece el bit NX, esa dirección de memoria no es ejecutable. Incluso si realizamos un desbordamiento de búfer y sobreescribimos la pila para redirigir el puntero de retorno a la pila donde reside nuestro código de shell, el código de shell no se ejecutaría porque estaría en la pila, que es una sección de memoria no ejecutable.
Esto es cuando usamos el comando return to libc attack para generar un shell. En lugar de utilizar el enfoque clásico para sobrescribir la dirección de retorno a la dirección del código de shell, usamos la dirección de la llamada libc system ().
Volver a PLT
La aleatorización del diseño de espacio de direcciones o ASLR es otro método para controlar los desbordamientos de búfer. Como dije en la sección anterior, las personas evitan NX al encontrar ejecutables cargados en la memoria por system.like libc. Esto fue posible porque era fácil identificar la ubicación de los ejecutables cargados del sistema. ASLR asignó al azar la dirección de estos ejecutables y, por lo tanto, redujo la probabilidad de generar un shell redirigiéndolos.
La razón por la que este ataque es posible es que en los ejecutables con bibliotecas enlazadas dinámicamente, la dirección de la función libc se puede obtener de PLT y GOT. La dirección PLT no es aleatoria y eso hace que el ataque sea fácil.