De acuerdo con esta respuesta, es posible compilar una aplicación basada en GCC sin ciertas técnicas de desbordamiento de búfer. Quizás esto sea posible incluso con Visual Studio.
¿Cómo puedo auditar un EXE o DLL dado si contiene las tecnologías de desbordamiento de búfer relevantes? ¿Es incluso posible?
ASLR es una función de tiempo de ejecución que proporciona el sistema operativo cuando se ejecuta el archivo binario; si el sistema operativo así lo decide, lo aplicará en la DLL cargada por el ejecutable, independientemente de cómo se hayan compilado el ejecutable y la DLL. Lo que se puede ver en el ejecutable es si es en sí mismo "reubicable" (es decir, como un archivo DLL), en cuyo caso ASLR también se puede aplicar en el propio código EXE.
La situación con DEP es casi similar: depende del sistema operativo (ayudado por lo que puede hacer el hardware) si la prohibición de "ejecutar" páginas de datos se aplicará o no. Lo mejor que puede encontrar al auditar un EXE es que puede incluir características que no pueden funcionar en presencia de un verdadero DEP, por ejemplo. un compilador JIT para algún idioma, que no se preocupó de advertir al sistema operativo sobre las transiciones entre el acceso a los datos y la ejecución.
Según Microsoft, SEHOP es de nuevo una característica provista por el sistema operativo que no depende de cómo se compiló el binario.
Hay son técnicas de "protección" de desbordamiento de búfer que se pueden ver al mirar el código compilado, por ejemplo. los "canaries" , porque dependen de algunos controles adicionales que deben estar presentes en el código producido. Desmontar el código los revelará, pero la inspección es tediosa. Algunas otras protecciones son puramente en tiempo de compilación, por ejemplo, cuando el compilador advierte sobre el uso potencialmente inseguro de una función similar a printf() - nuevamente, este tipo de protección no se puede ver en el ejecutable compilado.
Lea otras preguntas en las etiquetas audit windows programming buffer-overflow windows-8