Un ataque de "retorno a libc" es un ataque de seguridad informática que generalmente comienza con un desbordamiento del búfer en el que una dirección de retorno de subrutina en una pila de llamadas se reemplaza por una dirección de una subrutina que ya está presente en la memoria ejecutable del proceso , sin pasar por la característica de bit de no ejecución (si está presente) y librar al atacante de la necesidad de inyectar su propio código. El primer ejemplo de este ataque en la naturaleza fue aportado por Alexander Peslyak en la lista de correo de Bugtraq en 1997. [1]
En POSIX que cumplen las sistemas operativos de la biblioteca estándar de C (" libc
") se utiliza comúnmente para proporcionar un estándar entorno de ejecución para programas escritos en el lenguaje de programación C . Aunque el atacante podría hacer que el código regrese en cualquier lugar, libc
es el objetivo más probable, ya que casi siempre está vinculado al programa y proporciona llamadas útiles para un atacante (como la system
función utilizada para ejecutar comandos de shell).
Protección contra ataques de retorno a libc
Una pila no ejecutable puede evitar la explotación del desbordamiento del búfer, sin embargo, no puede evitar un ataque de retorno a libc porque en el ataque de retorno a libc solo se utiliza el código ejecutable existente. Por otro lado, estos ataques solo pueden llamar a funciones preexistentes. La protección contra la destrucción de la pila puede prevenir u obstruir la explotación, ya que puede detectar la corrupción de la pila y posiblemente eliminar el segmento comprometido.
El " blindaje ASCII " es una técnica que se puede utilizar para obstruir este tipo de ataque. Con el blindaje ASCII, todas las direcciones de las bibliotecas del sistema (por ejemplo, libc) contienen un byte NULL ( 0x00
). Esto se hace comúnmente colocándolos en los primeros 0x01010101
bytes de memoria (algunas páginas de más de 16 MB, denominada "región de armadura ASCII"), ya que cada dirección hasta (pero sin incluir) este valor contiene al menos un byte NULL. Esto hace que sea imposible ubicar código que contenga esas direcciones utilizando funciones de manipulación de cadenas como strcpy()
. Sin embargo, esta técnica no funciona si el atacante tiene una forma de desbordar bytes NULL en la pila. Si el programa es demasiado grande para caber en los primeros 16 MB , la protección puede ser incompleta. [2] Esta técnica es similar a otro ataque conocido como return-to-plt donde, en lugar de regresar a libc, el atacante usa las funciones de la Tabla de Enlace de Procedimiento (PLT) cargadas en el binario (por ejemplo, system@plt, execve@plt, sprintf@plt, strcpy@plt
). [3]
La aleatorización del diseño del espacio de direcciones (ASLR) hace que este tipo de ataque sea extremadamente improbable de tener éxito en máquinas de 64 bits, ya que las ubicaciones de memoria de las funciones son aleatorias. Para sistemas de 32 bits , sin embargo, ASLR ofrece poco beneficio ya que sólo hay 16 bits disponibles para la asignación al azar, y que puede ser derrotado por la fuerza bruta en cuestión de minutos. [4]
Ver también
Referencias
- ^ Diseñador solar (10 de agosto de 1997). "Bugtraq: Moverse por la pila no ejecutable (y arreglar)" .
- ^ David A. Wheeler (27 de enero de 2004). "Programador seguro: contrarrestar los desbordamientos del búfer" . IBM DeveloperWorks. Archivado desde el original el 18 de octubre de 2013.
- ^ Enfermedad (13 de mayo de 2011). "Desarrollo de exploits de Linux, parte 4: omisión de armadura ASCII + retorno a plt" (PDF) .
- ^ Shacham, H .; Page, M .; Pfaff, B .; Goh, EJ; Modadugu, N .; Boneh, D. (octubre de 2004). "Sobre la eficacia de la aleatorización del espacio de direcciones". Actas de la 11ª Conferencia de la ACM sobre seguridad informática y de comunicaciones (PDF) . págs. 298-307. doi : 10.1145 / 1030083.1030124 . ISBN 1-58113-961-6.
enlaces externos
- Omitir la pila no ejecutable durante la explotación usando return-to-libc por c0ntex en css.csail.mit.edu