stringtranslate.com

Ataque de retorno a libc

Un ataque de "retorno a libc" es un ataque de seguridad informática que suele comenzar con un desbordamiento de búfer en el que la dirección de retorno de una subrutina en una pila de llamadas se reemplaza por la dirección de una subrutina que ya está presente en la memoria ejecutable del proceso , lo que evita la función del bit de no ejecución (si está presente) y evita que el atacante tenga que inyectar su propio código. El primer ejemplo de este ataque en la vida real fue aportado por Alexander Peslyak en la lista de correo Bugtraq en 1997. [1]

En los sistemas operativos compatibles con POSIX, la biblioteca estándar C (" ") se usa comúnmente para proporcionar un entorno de ejecución estándar para programas escritos en el lenguaje de programación C. Aunque el atacante podría hacer que el código regrese en cualquier lugar, es el objetivo más probable, ya que casi siempre está vinculado al programa y proporciona llamadas útiles para un atacante (como la función utilizada para ejecutar comandos de shell).libclibcsystem

Protección contra ataques de retorno a libc

Una pila no ejecutable puede evitar la explotación de algunos desbordamientos de búfer, pero no puede evitar un ataque de retorno a libc porque en este último solo se utiliza 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 evitar 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ándolas en los primeros 0x01010101bytes de la memoria (unas pocas páginas más de 16 MB, denominadas la "región de blindaje ASCII"), ya que cada dirección hasta (pero sin incluir) este valor contiene al menos un byte NULL. Esto hace que sea imposible colocar 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 utiliza las funciones de la tabla de enlace de procedimientos (PLT) cargadas en el código independiente de la posición (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 en máquinas de 64 bits, ya que las ubicaciones de memoria de las funciones son aleatorias. Sin embargo, para los sistemas de 32 bits , la ASLR ofrece pocos beneficios, ya que solo hay 16 bits disponibles para la aleatorización y se pueden derrotar por fuerza bruta en cuestión de minutos. [4]

Véase también

Referencias

  1. ^ Solar Designer (10 de agosto de 1997). "Bugtraq: Cómo evitar la pila de errores no ejecutables (y cómo solucionarlos)".
  2. ^ David A. Wheeler (27 de enero de 2004). "Programador seguro: cómo contrarrestar los desbordamientos de búfer". IBM DeveloperWorks. Archivado desde el original el 18 de octubre de 2013.
  3. ^ Sickness (13 de mayo de 2011). "Desarrollo de exploits para Linux, parte 4: omisión de la protección ASCII + retorno a plt" (PDF) .
  4. ^ 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 las comunicaciones (PDF) . págs. 298–307. doi :10.1145/1030083.1030124. ISBN . 1-58113-961-6. Número de identificación del sujeto  5864467.

Enlaces externos