En seguridad informática , la protección del espacio ejecutable marca las regiones de memoria como no ejecutables, de modo que un intento de ejecutar código de máquina en estas regiones provocará una excepción . Utiliza características de hardware como el bit NX (bit de no ejecución) o, en algunos casos, la emulación de software de esas características. Sin embargo, las tecnologías que emulan o suministran un bit NX generalmente impondrán una sobrecarga medible, mientras que el uso de un bit NX suministrado por hardware no impone ninguna sobrecarga medible.
El Burroughs 5000 ofrecía soporte de hardware para la protección del espacio ejecutable cuando se presentó en 1961; esa capacidad se mantuvo en sus sucesores al menos hasta 2006. En su implementación de la arquitectura etiquetada , cada palabra de memoria tenía un bit de etiqueta oculto asociado que la designaba como código o datos. Por lo tanto, los programas de usuario no pueden escribir ni siquiera leer una palabra de programa, y las palabras de datos no se pueden ejecutar.
Si un sistema operativo puede marcar algunas o todas las regiones de memoria que se pueden escribir como no ejecutables, puede impedir que las áreas de memoria de pila y montón sean ejecutables. Esto ayuda a evitar que se produzcan ciertos ataques de desbordamiento de búfer , en particular los que inyectan y ejecutan código, como los gusanos Sasser y Blaster . Estos ataques dependen de que alguna parte de la memoria, normalmente la pila, sea tanto ejecutable como escribible; si no lo es, el ataque falla.
Muchos sistemas operativos implementan o tienen una política de protección del espacio ejecutable disponible. A continuación, se incluye una lista de dichos sistemas en orden alfabético, cada uno con las tecnologías ordenadas de la más reciente a la más antigua.
Para algunas tecnologías, existe un resumen que muestra las principales características que admite cada tecnología. El resumen está estructurado de la siguiente manera.
Una tecnología que proporcione emulación independiente de la arquitectura será funcional en todos los procesadores que no sean compatibles con el hardware. La línea "Otros compatibles" es para procesadores que permiten algún método de área gris, donde no existe un bit NX explícito pero el hardware permite emularlo de alguna manera.
A partir de Android 2.3 y posteriores, las arquitecturas que lo admiten tienen páginas no ejecutables de forma predeterminada, incluidas pilas y montones no ejecutables. [1] [2] [3]
El soporte inicial para el bit NX , en los procesadores x86-64 y IA-32 que lo admiten, apareció por primera vez en FreeBSD -CURRENT el 8 de junio de 2004. Ha estado en las versiones de FreeBSD desde la versión 5.3.
El núcleo Linux soporta el bit NX en procesadores x86-64 e IA-32 que lo soportan, como los procesadores modernos de 64 bits fabricados por AMD, Intel, Transmeta y VIA. El soporte para esta característica en el modo de 64 bits en CPU x86-64 fue añadido en 2004 por Andi Kleen, y más tarde ese mismo año, Ingo Molnár añadió soporte para ella en el modo de 32 bits en CPU de 64 bits. Estas características han sido parte de la línea principal del núcleo Linux desde el lanzamiento de la versión 2.6.8 del núcleo en agosto de 2004. [4]
La disponibilidad del bit NX en los núcleos x86 de 32 bits, que pueden ejecutarse tanto en CPU x86 de 32 bits como en CPU compatibles con IA-32 de 64 bits, es significativa porque un núcleo x86 de 32 bits normalmente no esperaría el bit NX que proporciona un AMD64 o IA-64 ; el parche habilitador NX asegura que estos núcleos intentarán usar el bit NX si está presente.
Algunas distribuciones de Linux de escritorio , como Fedora , Ubuntu y openSUSE , no habilitan la opción HIGHMEM64 de forma predeterminada en sus kernels predeterminados, que es necesaria para obtener acceso al bit NX en modo de 32 bits, porque el modo PAE que se requiere para usar el bit NX causa fallas de arranque en procesadores pre- Pentium Pro (incluido Pentium MMX) y Celeron M y Pentium M sin soporte para NX. Otros procesadores que no admiten PAE son AMD K6 y anteriores, Transmeta Crusoe , VIA C3 y anteriores, y Geode GX y LX. Las versiones de VMware Workstation anteriores a 4.0, las versiones de Parallels Workstation anteriores a 4.0 y Microsoft Virtual PC y Virtual Server no admiten PAE en el invitado. Fedora Core 6 y Ubuntu 9.10 y posteriores proporcionan un paquete kernel-PAE que admite PAE y NX.
La protección de memoria NX siempre ha estado disponible en Ubuntu para cualquier sistema que tuviera el hardware para soportarla y ejecutara el kernel de 64 bits o el kernel de servidor de 32 bits. El kernel de escritorio PAE de 32 bits (linux-image-generic-pae) en Ubuntu 9.10 y versiones posteriores también proporciona el modo PAE necesario para el hardware con la función de CPU NX. Para los sistemas que carecen de hardware NX, los kernels de 32 bits ahora proporcionan una aproximación de la función de CPU NX a través de la emulación de software que puede ayudar a bloquear muchos exploits que un atacante podría ejecutar desde la memoria de pila o montón.
La funcionalidad de no ejecución también ha estado presente para otros procesadores no x86 que admiten esta funcionalidad en muchas versiones.
El desarrollador del kernel de Red Hat , Ingo Molnár, publicó un parche para el kernel de Linux llamado Exec Shield para aproximarse y utilizar la funcionalidad NX en CPU x86 de 32 bits . El parche Exec Shield se publicó en la lista de correo del kernel de Linux el 2 de mayo de 2003, pero se rechazó su fusión con el kernel base porque implicaba algunos cambios intrusivos en el código central para manejar las partes complejas de la emulación. La compatibilidad con CPU heredadas de Exec Shield se aproxima a la emulación NX al rastrear el límite superior del segmento de código. Esto impone solo unos pocos ciclos de sobrecarga durante los cambios de contexto, lo que es, a todos los efectos, inmensurable. Para las CPU heredadas sin un bit NX, Exec Shield no puede proteger las páginas por debajo del límite del segmento de código; una llamada mprotect() para marcar como ejecutable la memoria superior, como la pila, también marcará como ejecutable toda la memoria por debajo de ese límite. Por lo tanto, en estas situaciones, los esquemas de Exec Shield fallan. Este es el costo de la baja sobrecarga de Exec Shield. Exec Shield comprueba dos marcas de encabezado ELF , que indican si la pila o el montón deben ser ejecutables. Se denominan PT_GNU_STACK y PT_GNU_HEAP respectivamente. Exec Shield permite configurar estos controles tanto para ejecutables binarios como para bibliotecas; si un ejecutable carga una biblioteca que requiere que se relaje una restricción determinada, el ejecutable heredará esa marca y se relajará esa restricción.
La tecnología PaX NX puede emular la funcionalidad de NX o utilizar un bit NX de hardware. PaX funciona en CPU x86 que no tienen el bit NX, como x86 de 32 bits. El núcleo Linux aún no se entrega con PaX (a fecha de mayo de 2007); el parche debe incorporarse manualmente.
PaX ofrece dos métodos de emulación de bits de NX, denominados SEGMEXEC y PAGEEXEC. El método SEGMEXEC impone una sobrecarga medible pero baja, normalmente inferior al 1%, que es una constante escalar en la que se incurre debido a la duplicación de memoria virtual utilizada para la separación entre la ejecución y los accesos a los datos. [5] SEGMEXEC también tiene el efecto de reducir a la mitad el espacio de direcciones virtuales de la tarea, lo que permite que la tarea acceda a menos memoria de la que normalmente podría. Esto no es un problema hasta que la tarea requiere acceso a más de la mitad del espacio de direcciones normal, lo que es poco frecuente. SEGMEXEC no hace que los programas utilicen más memoria del sistema (es decir, RAM), solo restringe la cantidad a la que pueden acceder. En las CPU de 32 bits, esto se convierte en 1,5 GB en lugar de 3 GB.
PaX proporciona un método similar a la aproximación de Exec Shield en PAGEEXEC como una forma de acelerar el proceso; sin embargo, cuando se marca como ejecutable una cantidad mayor de memoria, este método pierde sus protecciones. En estos casos, PaX recurre al método más antiguo de sobrecarga variable utilizado por PAGEEXEC para proteger las páginas que se encuentran por debajo del límite de CS, que puede convertirse en una operación de sobrecarga bastante alta en ciertos patrones de acceso a la memoria . Cuando se utiliza el método PAGEEXEC en una CPU que suministra un bit NX de hardware, se utiliza el bit NX de hardware, por lo que no se incurre en una sobrecarga significativa.
PaX ofrece restricciones mprotect() para evitar que los programas marquen la memoria de forma que generen memoria útil para un posible ataque . Esta política hace que ciertas aplicaciones dejen de funcionar, pero se puede desactivar para los programas afectados.
PaX permite el control individual sobre las siguientes funciones de la tecnología para cada ejecutable binario:
PaX ignora tanto PT_GNU_STACK como PT_GNU_HEAP. En el pasado, PaX tenía una opción de configuración para respetar estas configuraciones, pero esa opción se ha eliminado por razones de seguridad, ya que se consideró que no era útil. Los mismos resultados de PT_GNU_STACK normalmente se pueden obtener deshabilitando las restricciones mprotect(), ya que el programa normalmente mprotect() en la pila al cargar. Esto puede no ser siempre cierto; para situaciones en las que esto falla, simplemente deshabilitar tanto PAGEEXEC como SEGMEXEC eliminará efectivamente todas las restricciones de espacio ejecutable, lo que le dará a la tarea las mismas protecciones en su espacio ejecutable que un sistema que no sea PaX.
macOS para Intel es compatible con el bit NX en todas las CPU compatibles con Apple (desde Mac OS X 10.4.4, la primera versión de Intel, en adelante). Mac OS X 10.4 solo admitía la protección de pila NX. En Mac OS X 10.5, todos los ejecutables de 64 bits tienen pila y montón NX; protección W^X. Esto incluye x86-64 (Core 2 o posterior) y PowerPC de 64 bits en las Mac G5 .
A partir de NetBSD 2.0 y posteriores (9 de diciembre de 2004), las arquitecturas que lo admiten tienen una pila y un montón no ejecutables. [6]
Las arquitecturas que tienen granularidad por página consisten en: alpha , amd64 , hppa , i386 (con PAE ), powerpc (ibm4xx), sh5 , sparc ( sun4m , sun4d ), sparc64.
Las arquitecturas que solo pueden soportarlas con granularidad de región son: i386 (sin PAE), otras powerpc (como macppc).
Otras arquitecturas no se benefician de una pila o montón no ejecutable; NetBSD no utiliza de manera predeterminada ninguna emulación de software para ofrecer estas características en esas arquitecturas.
Una tecnología del sistema operativo OpenBSD , conocida como W^X, marca las páginas editables como no ejecutables de forma predeterminada en los procesadores que la admiten. En los procesadores x86 de 32 bits , el segmento de código está configurado para incluir solo una parte del espacio de direcciones, para brindar cierto nivel de protección del espacio ejecutable.
OpenBSD 3.3 se lanzó el 1 de mayo de 2003 y fue el primero en incluir W^X.
Solaris ha admitido la desactivación global de la ejecución de pila en procesadores SPARC desde Solaris 2.6 (1997); en Solaris 9 (2002), se agregó compatibilidad para desactivar la ejecución de pila por ejecutable.
La primera implementación de una pila no ejecutable para Windows (NT 4.0, 2000 y XP) fue publicada por SecureWave a través de su producto SecureStack en 2001, basado en el trabajo de PaX [7] [8]
A partir de Windows XP Service Pack 2 (2004) y Windows Server 2003 Service Pack 1 (2005), las características de NX se implementaron por primera vez en la arquitectura x86 . La protección del espacio ejecutable en Windows se denomina "Prevención de ejecución de datos" (DEP).
En Windows XP o Server 2003, la protección NX se utilizaba exclusivamente en servicios críticos de Windows de forma predeterminada. Si el procesador x86 admitía esta función en el hardware, las funciones NX se activaban automáticamente en Windows XP/Server 2003 de forma predeterminada. Si el procesador x86 no admitía la función, no se ofrecía protección.
Las primeras implementaciones de DEP no proporcionaban aleatorización del diseño del espacio de direcciones (ASLR), lo que permitía posibles ataques de retorno a libc que podrían haberse utilizado de manera factible para deshabilitar DEP durante un ataque. [9] La documentación de PaX explica en detalle por qué es necesaria la ASLR; [10] se produjo una prueba de concepto que detalla un método por el cual se podría eludir DEP en ausencia de ASLR. [11] Puede ser posible desarrollar un ataque exitoso si el atacante puede conocer la dirección de los datos preparados, como imágenes corruptas o MP3 .
Microsoft agregó la funcionalidad ASLR en Windows Vista y Windows Server 2008. En esta plataforma, DEP se implementa a través del uso automático del kernel PAE en Windows de 32 bits y el soporte nativo en kernels de 64 bits. Windows Vista DEP funciona marcando ciertas partes de la memoria como destinadas a contener solo datos, que el procesador habilitado con bits NX o XD entiende como no ejecutables. [12] En Windows, a partir de la versión Vista, si DEP está habilitado o deshabilitado para un proceso en particular se puede ver en la pestaña Procesos/Detalles en el Administrador de tareas de Windows .
Windows implementa DEP de software (sin el uso del bit NX ) a través del " Manejo seguro de excepciones estructuradas " (SafeSEH) de Microsoft. En el caso de aplicaciones compiladas correctamente, SafeSEH comprueba que, cuando se genera una excepción durante la ejecución del programa, el manejador de la excepción sea el definido por la aplicación tal como se compiló originalmente. El efecto de esta protección es que un atacante no puede agregar su propio manejador de excepciones que ha almacenado en una página de datos a través de una entrada de programa no verificada. [12] [13]
Cuando se admite NX, está habilitado de forma predeterminada. Windows permite que los programas controlen qué páginas no permiten la ejecución a través de su API , así como a través de los encabezados de sección en un archivo PE . En la API, el acceso en tiempo de ejecución al bit NX se expone a través de las llamadas a la API Win32 VirtualAlloc[Ex] y VirtualProtect[Ex] . Cada página puede marcarse individualmente como ejecutable o no ejecutable. A pesar de la falta de compatibilidad con hardware x86 anterior, se han proporcionado configuraciones de página ejecutables y no ejecutables desde el principio. En las CPU anteriores a NX, la presencia del atributo 'ejecutable' no tiene ningún efecto. Se documentó como si funcionara y, como resultado, la mayoría de los programadores lo usaron correctamente. En el formato de archivo PE, cada sección puede especificar su ejecutabilidad. El indicador de ejecución ha existido desde el comienzo del formato y los enlazadores estándar siempre han usado este indicador correctamente, incluso mucho antes del bit NX. Debido a esto, Windows puede aplicar el bit NX en programas antiguos. Suponiendo que el programador cumplió con las "mejores prácticas", las aplicaciones deberían funcionar correctamente ahora que NX está implementado. Solo en unos pocos casos ha habido problemas; el propio .NET Runtime de Microsoft tuvo problemas con el bit NX y se actualizó.
En la Xbox de Microsoft , aunque la CPU no tiene el bit NX, las versiones más nuevas del XDK establecen el límite del segmento de código al comienzo de la sección .data del núcleo (no debería haber código después de este punto en circunstancias normales). A partir de la versión 51xx, este cambio también se implementó en el núcleo de las nuevas Xbox. Esto rompió las técnicas que usaban los exploits antiguos para convertirse en un programa residente de terminación y permanencia . Sin embargo, rápidamente se lanzaron nuevos exploits que respaldaban esta nueva versión del núcleo porque la vulnerabilidad fundamental en el núcleo de Xbox no se vio afectada.
Cuando el código se escribe y se ejecuta en tiempo de ejecución (un compilador JIT es un ejemplo destacado), el compilador puede usarse potencialmente para producir código de explotación (por ejemplo, usando JIT Spray ) que ha sido marcado para su ejecución y, por lo tanto, no quedaría atrapado. [14] [15]
La programación orientada al retorno puede permitir que un atacante ejecute código arbitrario incluso cuando se aplica protección del espacio ejecutable.