Protección de espacio ejecutable - Executable space protection

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 . Hace uso de funciones de hardware como el bit NX ( bit de no ejecución) o, en algunos casos, la emulación de software de esas funciones. Sin embargo, las tecnologías que de alguna manera 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 una sobrecarga medible.

El Burroughs 5000 ofreció soporte de hardware para la protección del espacio ejecutable en su introducción en 1961; esa capacidad permaneció en sus sucesores hasta al menos 2006. En su implementación de arquitectura etiquetada , cada palabra de memoria tenía un bit de etiqueta oculto asociado que designaba su 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 grabables como no ejecutables, es posible que pueda evitar que las áreas de memoria de pila y montón sean ejecutables. Esto ayuda a prevenir ciertos de desbordamiento del búfer hazañas de tener éxito, en particular los que inyectar y ejecutar código, como los Sasser y Blaster gusanos. Estos ataques dependen de alguna parte de la memoria, generalmente la pila, que se puede escribir y ejecutar; si no es así, el ataque fracasa.

Implementaciones de SO

Muchos sistemas operativos implementan o tienen una política de protección de espacio ejecutable disponible. Aquí hay una lista de dichos sistemas en orden alfabético, cada uno con tecnologías ordenadas de la más nueva a la más antigua.

Para algunas tecnologías, hay un resumen que brinda las características principales que admite cada tecnología. El resumen está estructurado como se muestra a continuación.

  • Procesadores compatibles con hardware: (lista separada por comas de arquitecturas de CPU)
  • Emulación: (No) o (Arquitectura independiente) o (Lista separada por comas de arquitecturas de CPU)
  • Otros admitidos: (Ninguno) o (Lista separada por comas de arquitecturas de CPU)
  • Distribución estándar: (No) o (Sí) o (Lista separada por comas de distribuciones o versiones que admiten la tecnología)
  • Fecha de lanzamiento: (Fecha del primer lanzamiento)

Una tecnología que proporcione emulación independiente de la arquitectura será funcional en todos los procesadores que no sean compatibles con hardware. La línea "Otros admitidos" es para procesadores que permiten algún método de área gris, donde no existe un bit NX explícito pero el hardware permite que uno sea emulado de alguna manera.

Androide

A partir de Android 2.3 y versiones posteriores, las arquitecturas que lo admiten tienen páginas no ejecutables de forma predeterminada, incluida la pila y el montón no ejecutables.

FreeBSD

El soporte inicial para el bit NX , en procesadores x86-64 e IA-32 que lo soportan, 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.

Linux

El kernel de Linux admite el bit NX en los procesadores x86-64 e IA-32 que lo admiten, como los modernos procesadores de 64 bits fabricados por AMD, Intel, Transmeta y VIA. El soporte para esta función en el modo de 64 bits en las CPU x86-64 fue agregado en 2004 por Andi Kleen , y más tarde el mismo año, Ingo Molnar agregó soporte para ella en el modo de 32 bits en las CPU de 64 bits. Estas características han sido parte de la línea principal del kernel de Linux desde el lanzamiento de la versión 2.6.8 del kernel en agosto de 2004.

La disponibilidad del bit NX en kernels 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 kernel x86 de 32 bits normalmente no esperaría el bit NX que suministra un AMD64 o IA-64 ; el parche habilitador de NX asegura que estos núcleos intentarán utilizar 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 se requiere para obtener acceso al bit NX en modo de 32 bits, porque el modo PAE que se requiere para el uso del bit NX provoca fallas de arranque en procesadores anteriores a Pentium Pro (incluido Pentium MMX) y Celeron M y Pentium M sin compatibilidad con NX. Otros procesadores que no son compatibles con 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 son compatibles con 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 soportarlo 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 núcleos de 32 bits ahora proporcionan una aproximación de la función de la CPU NX a través de la emulación de software que puede ayudar a bloquear muchas vulnerabilidades que un atacante podría ejecutar desde la pila o la memoria del montón.

La funcionalidad de no ejecución también ha estado presente para otros procesadores que no son x86 que admiten esta funcionalidad en muchas versiones.

Escudo ejecutivo

El desarrollador del kernel de Red Hat, Ingo Molnar, lanzó un parche del kernel de Linux llamado Exec Shield para aproximar y utilizar la funcionalidad NX en CPU x86 de 32 bits . El parche Exec Shield fue lanzado a la lista de correo del kernel de Linux el 2 de mayo de 2003, pero fue rechazado por fusionarse con el kernel base porque involucraba algunos cambios intrusivos en el código del núcleo para manejar las partes complejas de la emulación. El soporte de CPU heredado 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 cual es inconmensurable a todos los efectos. Para las CPU heredadas sin un bit NX, Exec Shield no protege las páginas por debajo del límite del segmento de código; una llamada a mprotect () para marcar una memoria más alta, como la pila, el ejecutable marcará toda la memoria por debajo de ese límite como ejecutable también. Por lo tanto, en estas situaciones, los esquemas de Exec Shield fallan. Este es el costo de los bajos gastos generales de Exec Shield. Exec Shield busca dos marcas de encabezado ELF , que dictan si la pila o el montón deben ser ejecutables. Estos se denominan PT_GNU_STACK y PT_GNU_HEAP respectivamente. Exec Shield permite que estos controles se establezcan tanto para ejecutables binarios como para bibliotecas; si un ejecutable carga una biblioteca que requiere una restricción dada relajada, el ejecutable heredará esa marca y relajará esa restricción.

Paz

La tecnología PaX NX puede emular la funcionalidad 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 kernel de Linux aún no se incluye con PaX (a partir de mayo de 2007); el parche debe combinarse manualmente.

PaX proporciona dos métodos de emulación de bits NX, llamados SEGMEXEC y PAGEEXEC. El método SEGMEXEC impone una sobrecarga medible pero baja, generalmente menos del 1%, que es un escalar constante en el que se incurre debido a la duplicación de la memoria virtual utilizada para la separación entre la ejecución y los accesos a los datos. 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 requiera acceso a más de la mitad del espacio de direcciones normal, lo cual es poco común. 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 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 aceleración; sin embargo, cuando la memoria superior se marca como ejecutable, este método pierde sus protecciones. En estos casos, PaX recurre al antiguo método de sobrecarga variable utilizado por PAGEEXEC para proteger las páginas 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 usa el método PAGEEXEC en una CPU que suministra un bit NX de hardware, se usa el bit NX de hardware, por lo que no se incurre en una sobrecarga significativa.

PaX proporciona restricciones de mprotect () para evitar que los programas marquen la memoria de formas que produzcan memoria útil para un posible exploit . Esta política hace que ciertas aplicaciones dejen de funcionar, pero se puede deshabilitar para los programas afectados.

PaX permite el control individual de las siguientes funciones de la tecnología para cada ejecutable binario:

  • PAGEEXEC
  • SEGMEXEC
  • restricciones de mprotect ()
  • Emulación de trampolín
  • Base ejecutable aleatoria
  • Base mmap () aleatorizada

PaX ignora tanto PT_GNU_STACK como PT_GNU_HEAP. En el pasado, PaX tenía una opción de configuración para respetar esta configuración, pero esa opción se eliminó por razones de seguridad, ya que no se consideró útil. Los mismos resultados de PT_GNU_STACK normalmente se pueden lograr deshabilitando las restricciones de mprotect (), ya que el programa normalmente mprotect () la pila en carga. Puede que esto no siempre sea cierto; para situaciones en las que esto falla, simplemente deshabilitar tanto PAGEEXEC como SEGMEXEC eliminará efectivamente todas las restricciones de espacio ejecutable, dando a la tarea las mismas protecciones en su espacio ejecutable que un sistema que no es PaX.

Mac OS

macOS para Intel admite 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 .

NetBSD

A partir de NetBSD 2.0 y posteriores (9 de diciembre de 2004), las arquitecturas que lo soportan tienen pila y montón no ejecutables.

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 admitirlas con granularidad de región son: i386 (sin PAE), otras powerpc (como macppc).

Otras arquitecturas no se benefician de la pila o el montón no ejecutable; NetBSD no utiliza por defecto ninguna emulación de software para ofrecer estas características en esas arquitecturas.

OpenBSD

Artículo principal: W ^ X

Una tecnología del sistema operativo OpenBSD , conocida como W ^ X, marca las páginas grabables de forma predeterminada como no ejecutables en los procesadores que lo 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 proporcionar algún nivel de protección del espacio ejecutable.

OpenBSD 3.3 se envió el 1 de mayo de 2003 y fue el primero en incluir W ^ X.

  • Procesadores compatibles con hardware: Alpha , AMD64 , HPPA , SPARC
  • Emulación: IA-32 (x86)
  • Otros admitidos: Ninguno
  • Distribución estándar: sí
  • Fecha de lanzamiento: 1 de mayo de 2003

Solaris

Solaris ha admitido la desactivación global de la ejecución de la pila en procesadores SPARC desde Solaris 2.6 (1997); en Solaris 9 (2002), se agregó soporte para deshabilitar la ejecución de la pila por ejecutable.

Ventanas

A partir de Windows XP Service Pack 2 (2004) y Windows Server 2003 Service Pack 1 (2005), las funciones 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).

Bajo Windows XP o Server 2003 NX, la protección se usó en servicios críticos de Windows exclusivamente de forma predeterminada. Si el procesador x86 admitía esta función en el hardware, las funciones NX se activaron automáticamente en Windows XP / Server 2003 de forma predeterminada. Si la función no era compatible con el procesador x86, no se proporcionó protección.

Las primeras implementaciones de DEP no proporcionaron aleatorización de diseño de espacio de direcciones (ASLR), lo que permitió posibles ataques de retorno a libc que podrían haberse utilizado de manera factible para deshabilitar DEP durante un ataque. La documentación de PaX explica por qué es necesario ASLR; se produjo una prueba de concepto que detalla un método mediante el cual DEP podría eludirse en ausencia de ASLR. Es 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 mediante el uso automático del kernel PAE en Windows de 32 bits y el soporte nativo en kernels de 64 bits. El DEP de Windows Vista funciona marcando ciertas partes de la memoria como destinadas a contener solo datos, que el procesador habilitado para bits NX o XD luego entiende como no ejecutables. En Windows, desde 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 el software DEP (sin el uso del bit NX) a través del "Manejo de excepciones estructurado seguro" (SafeSEH) de Microsoft. Para aplicaciones compiladas correctamente, SafeSEH comprueba que, cuando se genera una excepción durante la ejecución del programa, el controlador de la excepción es uno 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 controlador de excepciones que ha almacenado en una página de datos a través de una entrada de programa no verificada.

Cuando se admite NX, está habilitado de forma predeterminada. Windows permite a los programas controlar 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 de Win32 VirtualAlloc [Ex] y VirtualProtect [Ex] . Cada página puede marcarse individualmente como ejecutable o no ejecutable. A pesar de la falta de soporte de 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 capacidad de ejecución. La bandera de ejecución ha existido desde el comienzo del formato y los enlazadores estándar siempre han usado esta bandera 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á realmente implementado. Solo en unos pocos casos ha habido problemas; El propio .NET Runtime de Microsoft tuvo problemas con el bit NX y se actualizó.

  • Procesadores compatibles con hardware: x86-64 (AMD64 e Intel 64), IA-64 , Efficeon , Pentium M (revisiones posteriores), AMD Sempron (revisiones posteriores)
  • Emulación: si
  • Otros admitidos: Ninguno
  • Distribución estándar: Post Windows XP
  • Fecha de lanzamiento: 6 de agosto de 2004

Xbox

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 kernel (ningún código debería estar después de este punto en circunstancias normales). A partir de la versión 51xx, este cambio también se implementó en el kernel de las nuevas Xbox. Esto rompió las técnicas que los antiguos exploits usaban para convertirse en TSR . Sin embargo, rápidamente se lanzaron nuevas versiones compatibles con esta nueva versión porque el exploit fundamental no se vio afectado.

Limitaciones

Cuando el código se escribe y ejecuta en tiempo de ejecución (un compilador JIT es un ejemplo destacado), el compilador puede potencialmente usarse para producir código de explotación (por ejemplo, usando JIT Spray ) que ha sido marcado para ejecución y por lo tanto no quedaría atrapado.

La programación orientada al retorno puede permitir que un atacante ejecute código arbitrario incluso cuando se aplica la protección del espacio ejecutable.

Ver también

Referencias