"Rompiendo la pila por diversión y ganancias" - Remediaciones

Question

"Rompiendo la pila por diversión y ganancias" - Remediaciones

#1 de flerb (2 votos)

1

Estaba leyendo este famoso artículo:

Aleph One: rompiendo la pila por diversión y beneficio

y no tengo idea de cómo stack canaries / NX support / ASLR puede evitar un ataque así. Intentaré explicarme mejor. Hablando estrictamente:

apilar canarios: valores aleatorios antes de RET
Compatibilidad con NX: no hay un indicador x para la pila (y el montón)
ASLR: aleatorización de espacio de direcciones

Teniendo en cuenta este ejemplo:

example3.c:
------------------------------------------------------------------------------
void function(int a, int b, int c) {
   char buffer1[5];
   char buffer2[10];
   int *ret;

   ret = buffer1 + 12;
   (*ret) += 8;
}

void main() {
  int x;

  x = 0;
  function(1,2,3);
  x = 1;
  printf("%d\n",x);
}
------------------------------------------------------------------------------

En este caso:

Los canarios de pila se omiten (solo cambio el valor RET)
soporte NX: inútil
ASLR: inútil (omito la instrucción x = 1 agregando un desplazamiento)

No entiendo cómo las soluciones anteriores pueden evitar un ejemplo como ese.

protection memory

pregunta Alvin 09.08.2017 - 12:01

fuente

1 respuesta

Lea otras preguntas en las etiquetas protection memory

Problemas de seguridad relacionados con la clave API en el sitio web Protección de datos después de que la computadora portátil se extravíe o sea robada

score 2 · Answer 1

El santo grial de destruir la pila es obtener el control de un puntero para que puedas apuntarlo al código malicioso que se ejecutará. Tiene que haber un desbordamiento en el propio programa que está siendo explotado. En este ejemplo 3.c, la devolución se puede controlar fácilmente porque es un programa cuidadosamente diseñado. Es una prueba del concepto de cómo desbordar un búfer vulnerable para obtener el control de un puntero, en este caso, el puntero de retorno.

En una explotación real, de alguna manera, el programa malintencionado que se va a ejecutar debe cargarse en la memoria del ejecutable y el puntero de instrucción debe apuntar hacia él.

Las razones por las que las protecciones que mencionaste causan dificultades en el mundo real:

Encuentre un desbordamiento de búfer en el programa, no puede simplemente escribir uno allí. Digamos que encontramos uno, pero hay canarios al estilo Stackguard entre los buffers de pila y cualquier otro dato de marco de pila, como la dirección de retorno. Encuentre y escriba perfectamente sobre los canarios de pila cuando los desborda para que no se alteren, y espere que la dirección de retorno no se haya guardado en otro lugar al estilo StackShield por el programa que estamos tratando de solucionar, y la pila no ha sido barajada Heroicamente tenemos un puntero controlable.

También conseguimos que el programa malicioso se cargue en la memoria, ¿dónde está?

ASLR : diseñado para aleatorizar el montón ejecutable, brk (): imágenes de biblioteca, mmap (): montón administrado, pila de espacio de usuario y pila de espacio del kernel.

Eso es desafortunado, y el seguimiento de las bibliotecas y la memoria de mapas es difícil ( A menos que seas un artista ), así que lo colocamos en la pila o el montón, lo cual es más fácil de todos modos. Lo conseguimos allí, colocamos el puntero en él, pero luego las páginas de memoria no ejecutables impiden su ejecución.

Las vulnerabilidades de retorno a la biblioteca, como la que he vinculado anteriormente, se desarrollaron porque las bibliotecas son necesariamente ejecutables y están presentes.