Me preguntaba por qué almacenar el programa completo en ROM no evita los ataques de desbordamiento de búfer, retorno a libc.
¿El código aún está cargado en RAM antes de ejecutarse, lo que lo hace vulnerable al ataque de flujo de control? (si ese es el caso, ¿por qué las páginas de códigos no están marcadas como de solo lectura por MMU?)
Oups, hay diferentes puntos en tu pregunta ...
¿Por qué no se almacena el código para libc de otro programa en la ROM?
Por definición, la ROM es de solo lectura, lo que significa que sería imposible actualizar libc ni ningún programa si se almacenara en la ROM
¿Por qué las páginas de códigos no están marcadas como de solo lectura a nivel de MMU?
Se están marcados como de solo lectura. Lamentablemente, no tiene uso contra los ataques de desbordamiento de búfer, retorno a libc
¿Qué hace que esos ataques sean posibles?
La dirección de retorno no se almacena en el código, sino en la pila. Todos los idiomas actuales (más allá de mediados de los años 60 Fortran 4 ...) también almacenan las variables locales en la pila para permitir el multihilo y la recursión. Eso significa que un programa no tiene una protección especial de la pila y se desborda un búfer local, teóricamente podría volver a escribir la dirección de retorno y así ejecutar un código libc arbitrario.
Debe notarse que la mayoría de los compiladores actuales implementan protecciones de pila para mitigar esas amenazas.
La sección de texto de los ejecutables (donde reside su código) debe marcarse como ejecutable. De lo contrario, no podrá ejecutar ninguna de las instrucciones de su código.
Existen mitigaciones de reutilización de código (ROP), y puede encontrar más información sobre la implementación de grsec en: enlace
Lea otras preguntas en las etiquetas buffer-overflow