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 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 ++).