stringtranslate.com

Protección del espacio ejecutable

En seguridad informática , la protección del espacio ejecutable marca 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 emulan o suministran un bit NX generalmente impondrán una sobrecarga mensurable, mientras que el uso de un bit NX suministrado por hardware no impone una sobrecarga mensurable.

El Burroughs 5000 ofreció soporte de hardware para la protección del espacio ejecutable desde 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 tanto, los programas de usuario no pueden escribir ni siquiera leer una palabra de programa y las palabras de datos no pueden ejecutarse.

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 evitar que ciertos ataques de desbordamiento del búfer tengan éxito, particularmente aquellos que inyectan y ejecutan código, como los gusanos Sasser y Blaster . Estos ataques dependen de que una parte de la memoria, generalmente la pila, sea escribible y ejecutable; si no es así, el ataque falla.

Implementaciones de sistema operativo

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 del más nuevo al más antiguo.

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.

Una tecnología que proporcione emulación de arquitectura independiente será funcional en todos los procesadores que no sean compatibles con 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.

Androide

A partir de Android 2.3 y posteriores, las arquitecturas que lo admiten tienen páginas no ejecutables de forma predeterminada, incluidas la pila y el montón no ejecutables. [1] [2] [3]

FreeBSD

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

linux

El kernel de Linux admite el bit NX en procesadores x86-64 e IA-32 que lo admiten, como los procesadores modernos de 64 bits fabricados por AMD, Intel, Transmeta y VIA. Andi Kleen agregó soporte para esta función en modo de 64 bits en CPU x86-64 en 2004, y más tarde, ese mismo año, Ingo Molnár agregó soporte en modo de 32 bits en 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. [4]

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 importante 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 garantiza 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 es necesaria 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 fallos 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 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 la memoria NX siempre ha estado disponible en Ubuntu para cualquier sistema que tuviera el hardware para admitirla y ejecutara el kernel de 64 bits o el kernel del 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 una 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 que no son x86 que admiten esta funcionalidad en muchas versiones.

Escudo ejecutivo

El desarrollador del kernel de Red Hat, Ingo Molnár, 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 se lanzó 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 implicaba algunos cambios intrusivos en el código central para poder manejar las partes complejas de la emulación. La compatibilidad con CPU heredada de Exec Shield se aproxima a la emulación de NX mediante el seguimiento del límite superior del segmento de código. Esto impone sólo unos pocos ciclos de sobrecarga durante los cambios de contexto, lo cual es, a todos los efectos, inconmensurable. Para CPU heredadas sin un bit NX, Exec Shield no protege las páginas por debajo del límite de segmento de código; una llamada a mprotect() para marcar memoria superior, como la pila, ejecutable también marcará toda la memoria por debajo de ese límite como ejecutable. Por lo tanto, en estas situaciones, los planes 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 configurar estos controles 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 de NX o utilizar un bit de hardware NX. PaX funciona en CPU x86 que no tienen el bit NX, como las x86 de 32 bits. El kernel de Linux todavía no se incluye con PaX (en mayo de 2007); el parche debe fusionarse 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 incurrido debido a la duplicación de la 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, permitiendo 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 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 las CPU de 32 bits, esto pasa a ser 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 páginas por debajo del límite de CS, lo 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 proporciona restricciones mprotect() para evitar que los programas marquen la memoria de manera que produzcan memoria útil para un posible exploit . 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 eliminó por razones de seguridad, ya que se consideró no ú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 al cargar. Puede que esto no siempre sea cierto; para situaciones en las que esto falla, simplemente deshabilitar PAGEEXEC y SEGMEXEC eliminará efectivamente todas las restricciones de espacio ejecutable, brindando a la tarea las mismas protecciones en su espacio ejecutable que un sistema que no sea 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 admiten tienen pila y montón no ejecutables. [6]

Las arquitecturas que tienen granularidad por página constan de: alpha , amd64 , hppa , i386 (con PAE ), powerpc (ibm4xx), sh5 , sparc ( sun4m , sun4d ), sparc64.

Las arquitecturas que solo pueden admitirlas con granularidad regional son: i386 (sin PAE) y otros powerpc (como macppc).

Otras arquitecturas no se benefician de la pila o el montón no ejecutables; NetBSD no utiliza de forma predeterminada ninguna emulación de software para ofrecer estas funciones en esas arquitecturas.

OpenBSD

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 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

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ó soporte para deshabilitar la ejecución de la pila por ejecutable.

ventanas

SecureWave publicó la primera implementación de una pila no ejecutable para Windows (NT 4.0, 2000 y XP) a través de su producto SecureStack en 2001, basada 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 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).

En Windows XP o Server 2003, la protección NX se utilizaba exclusivamente de forma predeterminada en los servicios críticos de Windows . 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 la característica no era compatible con el procesador x86, entonces no se brindaba 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 para desactivar DEP durante un ataque. [9] La documentación de PaX explica por qué es necesario ASLR; [10] se produjo una prueba de concepto que detalla un método mediante el cual se podría eludir el DEP en ausencia de ASLR. [11] 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. Windows Vista DEP funciona marcando ciertas partes de la memoria como destinadas a contener solo datos, que el procesador habilitado para 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 el software DEP (sin el uso del bit NX ) a través del " Manejo estructurado seguro de excepciones" de Microsoft (SafeSEH). Para aplicaciones compiladas correctamente, SafeSEH verifica que, cuando se genera una excepción durante la ejecución del programa, el controlador de la excepción sea 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 mediante 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 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, desde el principio se han proporcionado configuraciones de página tanto ejecutables como no ejecutables. En las CPU anteriores a NX, la presencia del atributo "ejecutable" no tiene ningún efecto. Estaba documentado como si funcionara y, como resultado, la mayoría de los programadores lo utilizaron 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 imponer 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 realmente se aplica. Sólo en unos pocos casos ha habido problemas; El propio .NET Runtime de Microsoft tuvo problemas con el bit NX y se actualizó.

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 viejos exploits usaban para convertirse en un programa de terminación y permanencia residente . Sin embargo, rápidamente se lanzaron nuevos exploits compatibles con esta nueva versión del kernel porque la vulnerabilidad fundamental en el kernel de Xbox no se vio afectada.

Limitaciones

Cuando el código se escribe y 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 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 la protección del espacio ejecutable.

Ver también

Referencias

  1. ^ "Mejoras de seguridad en la administración de memoria", Descripción general de seguridad de Android, consultado el 29/07/2012.
  2. ^ "Cambio de código de Android que habilita NX de forma predeterminada". Cambio del repositorio fuente de Android . Consultado el 27 de agosto de 2019 .
  3. ^ "Requisito de compatibilidad de Android para NX". Revisión del código de Android . Consultado el 27 de agosto de 2019 .
  4. ^ "Núcleo de Linux 2.6.8". kernelnewbies.org . 2004-08-14 . Consultado el 1 de agosto de 2015 .
  5. «Documentación PaX SEGMEXEC» (TXT) . pax.grsecurity.net . 10 de septiembre de 2004 . Consultado el 25 de enero de 2015 .
  6. ^ NetBSD, Pila y montón no ejecutables, consultado el 14/07/2011.
  7. ^ "SecureWave | SecureNT". 2001-03-31. Archivado desde el original el 31 de marzo de 2001 . Consultado el 27 de diciembre de 2023 .
  8. ^ "Página de inicio de PaX: la implementación del indicador PAGE_EXEC para IA-32". 2001-03-31. Archivado desde el original el 31 de marzo de 2001 . Consultado el 27 de diciembre de 2023 .
  9. ^ "Blog sobre ciberterror". Archivado desde el original el 9 de febrero de 2012 . Consultado el 8 de enero de 2008 .
  10. ^ "aleatorización del diseño del espacio de direcciones". Proyecto PaX .
  11. ^ "Desinformado - vol 2 artículo 4". Archivado desde el original el 12 de marzo de 2016 . Consultado el 19 de marzo de 2010 .
  12. ^ ab "Una descripción detallada de la función Prevención de ejecución de datos (DEP) en Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005 y Windows Server 2003". Microsoft . 2006-09-26. Archivado desde el original el 11 de septiembre de 2014 . Consultado el 11 de julio de 2008 .
  13. ^ Johnson, Pedro. "Manual de usuario de Yasm, win32: Manejo seguro de excepciones estructuradas". Tortall Networks: código abierto y software libre . Archivado desde el original el 2 de enero de 2015 . Consultado el 27 de septiembre de 2015 .
  14. ^ Dion Blazakis. "Explotación de intérpretes: inferencia de punteros y pulverización JIT" (PDF) .
  15. ^ Alexey Sintsov (5 de marzo de 2010). "Escribir JIT-Spray Shellcode por diversión y ganancias" (PDF) . Archivado desde el original (PDF) el 4 de marzo de 2016.