This article needs additional citations for verification. (September 2007) |
Exec Shield es un proyecto que se inició en Red Hat , Inc. a finales de 2002 con el objetivo de reducir el riesgo de ataques remotos automatizados o de gusanos en sistemas Linux. El primer resultado del proyecto fue un parche de seguridad para el kernel de Linux que emula un bit NX en CPU x86 que carecen de una implementación nativa de NX en hardware. Si bien el proyecto Exec Shield ha tenido muchos otros componentes, algunas personas se refieren a este primer parche como Exec Shield.
El primer parche de Exec Shield intenta marcar la memoria de datos como no ejecutable y la memoria de programa como no escribible. Esto suprime muchas vulnerabilidades de seguridad , como las que surgen de desbordamientos de búfer y otras técnicas que se basan en sobrescribir datos e insertar código en esas estructuras. Exec Shield también proporciona cierta aleatorización del diseño del espacio de direcciones para mmap () y la base del montón.
El parche aumenta además la dificultad de insertar y ejecutar shellcode , lo que hace que la mayoría de los exploits sean ineficaces. No es necesario volver a compilar la aplicación para utilizar completamente exec-shield, aunque algunas aplicaciones ( Mono , Wine , XEmacs , Mplayer ) no son totalmente compatibles.
Otras características que surgieron del proyecto Exec Shield fueron los ejecutables independientes de la posición (PIE), el parche de aleatorización del espacio de direcciones para los núcleos de Linux, un amplio conjunto de controles de seguridad internos de glibc que hacen que las explotaciones de cadenas de formato y montón sean casi imposibles, la característica GCC Fortify Source y la portabilidad y fusión de la característica de protección de pila GCC .
Exec Shield funciona en todas las CPU x86 que utilizan el límite de segmento de código. Debido a la forma en que funciona Exec Shield, es muy ligero; sin embargo, no protegerá por completo los diseños de memoria virtual arbitrarios . Si se aumenta el límite de CS, por ejemplo, al llamar a mprotect() para que se pueda ejecutar una memoria mayor, entonces las protecciones se pierden por debajo de ese límite. Ingo Molnar señala esto en una conversación por correo electrónico. La mayoría de las aplicaciones son bastante sensatas en esto; la pila (la parte importante) al menos termina por encima de cualquier biblioteca asignada, por lo que no se vuelve ejecutable excepto por llamadas explícitas de la aplicación.
A partir de agosto de 2004, ningún proyecto de Exec Shield ha intentado aplicar protecciones de memoria restringiendo mprotect () en ninguna arquitectura; aunque la memoria puede no ser ejecutable inicialmente, puede volverse ejecutable más adelante, por lo que el núcleo permitirá que una aplicación marque páginas de memoria como ejecutables y escribibles al mismo tiempo. Sin embargo, en cooperación con el proyecto Security-Enhanced Linux (SELinux), la política estándar para la distribución Fedora Core prohíbe este comportamiento para la mayoría de los ejecutables, con solo unas pocas excepciones por razones de compatibilidad.
Exec Shield fue desarrollado por varias personas en Red Hat; el primer parche fue lanzado por Ingo Molnar de Red Hat y se lanzó por primera vez en mayo de 2003. Es parte de Fedora Core 1 a 6 y de Red Hat Enterprise Linux desde la versión 3. [1] [2] Otras personas involucradas incluyen a Jakub Jelínek, Ulrich Drepper, Richard Henderson y Arjan van de Ven.
Molnar comentó en 2007 en LWN.net que "partes de [exec-shield] fueron enviadas al servidor, pero una buena parte no lo fue". [3]