Los estudiantes se muestran escépticos de que apagar pilas no ejecutables, apagar canarios y apagar ASLR representa un entorno realista. Si PaX, DEP, W ^ X, etc., son eficaces para detener los ataques de desbordamiento de búfer, ¿sigue siendo valioso aprender sobre ellos?
Absolutamente. ASLR y DEP Son medidas de defensa en profundidad. Existen vulnerabilidades que pueden omitir cada una de ellas (para un ejemplo del mundo real, consulte La vulnerabilidad de Pwn2Own de Peter Vreugdenhil que usó contra IE ).
Todo lo que necesita para evitar ASLR para Windows es una vulnerabilidad de divulgación de información que le permitirá conocer la dirección base de una DLL cargada en el proceso (esa fue la primera vulnerabilidad que Vreugdenhil explotó). A partir de eso, puedes usar un ataque ret-to-libc para llamar a cualquier función en esa DLL.
La conclusión: los desbordamientos de la pila (y del montón) siguen siendo relevantes hoy en día. Son más difíciles de explotar de lo que solían ser, pero siguen siendo relevantes.
Además de las excelentes respuestas concisas de @Larry's y @ SteveS, quiero señalar un punto muy importante:
Los estudiantes se muestran escépticos de que apagar pilas no ejecutables, apagar canarios y apagar ASLR representa un entorno realista.
Esperemos que esto sea cierto para los sistemas de sus estudiantes.
En el resto del mundo, sin embargo, esto sigue siendo muy común, por desgracia. Además de las plataformas que no son compatibles con estos, siempre hay productos mal construidos que requieren apagarlos, versiones anteriores del sistema operativo e incluso malas configuraciones erróneas.
Todavía muy realista, por desgracia.
Además de todo eso, 2 comentarios más de un punto de vista educativo:
1. alguien tiene que construir esas defensas, ¿verdad?
2. Incluso si hipotéticamente tenían razón, you only need pointers in C/C++ no significa que un desarrollador de Java no debería aprender cómo estas cosas funcionan dentro de la computadora, ¿verdad?
Sí. Además de los sistemas en los que los desbordamientos de búfer conducen a explotaciones exitosas, las explicaciones completas sobre desbordamientos de búfer son siempre una excelente manera de demostrar cómo debe pensar en la seguridad. En lugar de concentrarse en cómo debe ejecutarse la aplicación, vea qué se puede hacer para hacer que la aplicación descarrile.
Además, independientemente de la ejecución de la pila y la cantidad de canarios que instales que gritan, un desbordamiento de búfer es un error. Todas esas características de seguridad simplemente alteran las consecuencias del error: en lugar de un shell remoto, "simplemente" se produce un bloqueo inmediato de la aplicación. No preocuparse por los bloqueos de aplicaciones (en particular, los bloqueos que pueden activarse de forma remota) es, en el mejor de los casos, una programación muy descuidada. ¡No en mi reloj!
Para completar, las pilas y los canarios no ejecutables no evitan los desbordamientos del búfer; simplemente desactivan algunas de las formas fáciles de explotar los desbordamientos de búfer. El desbordamiento de búfer tradicional consiste en reemplazar la dirección de retorno con un puntero a código malicioso que se carga como parte de los datos que desbordaron el búfer; El código malicioso se ejecuta cuando la función vuelve. La pila no ejecutable significa que el atacante no podrá colocar su código en la pila (tendrá que organizar un salto en algún código de biblioteca, por ejemplo, la implementación execve() en la biblioteca estándar). El canario evita que se utilice la dirección de retorno si se desbordó un búfer de pila (asumiendo que el desbordamiento es "simple": una parte contigua de datos). Pero el desbordamiento también puede sobrescribir algunos otros datos, incluidos los punteros de función (en particular en el contexto de C ++).
Ya hay respuestas geniales aquí, así que no intentaré volver a cubrirlas. Sin embargo, ya que estamos hablando de mecanismos que evitan el desbordamiento del búfer, me gustaría enfatizar algo que les gustaría transmitir a sus estudiantes:
El hecho de que un programa esté escrito en Java no significa que no hay desbordamientos de búfer. La máquina virtual de Java en sí no está implementada en Java; se implementa en (probablemente) C o C ++, que son tan propensos a los desbordamientos de búfer como cualquier otro programa.
Además de eso, hay muchas implementaciones de la JVM . Por cada uno que arregles, hay diez más que probablemente todavía sean vulnerables.
Espero no haber tropezado con mi caja de jabón ... :-)
Me gustaría responder desde el punto de vista de un estudiante que recientemente comenzó a aprender en profundidad sobre los Ataques de Desbordamiento de Buffer. Yo también tenía las mismas inquietudes y tenía dudas sobre los beneficios de aprender acerca de los ataques de desbordamiento de búfer, pero teniendo en cuenta lo mucho que he aprendido para obtenerlo, estoy muy contento de haber elegido hacerlo.
Hasta ahora he tenido que:
Estas habilidades son muy transferibles y no me arrepiento. Desafortunadamente, no tengo a alguien que me enseñe esto. He tenido que trabajar con tutoriales en vídeo y códigos de ejemplo para el proyecto de mi Máster. Los ataques de desbordamiento de búfer pueden ser un problema de seguridad de TI menor que hace 5-10 años, pero definitivamente puede servir como un trampolín para conocer amenazas más complejas o contemporáneas.
No, no enseñes desbordamientos de búfer. Enseñar la corrupción de la memoria. Enseñar primitivas del exploit. Sí, también necesitan conocer la historia, pero no debería ocupar más de la mitad de la clase. Digo que cuando se trata de la tarea real, dales desafíos que tengan todas las protecciones de memoria habilitadas, pero tal vez debilite el servidor vulnerable, con algunas revelaciones de memoria que dan pistas en varias compensaciones.
También deben entender que muchas protecciones de memoria son en su mayoría trucos, y muchas veces las "compensaciones aleatorias" no son realmente tan aleatorias como usted podría pensar que son. Deben aprender a reconocer los errores y usar los errores que tienen para atacar las cosas que saben, para que puedan llegar a las cosas que quieren.
Deben estar pensando en sobrescribir los punteros de función en lugar de direcciones de retorno, y saltar al código ejecutable conocido (ret2libc, ROP) en lugar de saltar al código de shell en la pila / montón.
Siendo un estudiante universitario recién salido de una clase de c ++, sí, sé que no es lo mismo ..., pero mi profesor se aseguró de poner mayor énfasis en la enseñanza sobre los desbordamientos de búfer y cómo prevenirlos, y realmente lo aliento Continúe enseñando sobre desbordamientos de búfer en cualquier curso que enseñe programación. No les puede hacer daño hacerlo.
Lea otras preguntas en las etiquetas attacks user-education source-code appsec buffer-overflow