W^X ("write xorexecute", pronunciado W xor X ) es una característica de seguridad en sistemas operativos y máquinas virtuales . Es una política de protección de memoria por la cual cada página en el espacio de direcciones de un proceso o kernel puede ser escribible o ejecutable , pero no ambas. Sin dicha protección, un programa puede escribir (como datos "W") instrucciones de CPU en un área de memoria destinada a datos y luego ejecutar (como ejecutable "X"; o leer-ejecutar "RX") esas instrucciones. Esto puede ser peligroso si el escritor de la memoria es malintencionado. W^X es la terminología similar a Unix para un uso estricto del concepto general de protección del espacio ejecutable , controlado a través de la llamada al sistema.mprotect
W^X es relativamente simple en arquitecturas de procesador que admiten permisos de página de grano fino, como SPARC y SPARC64 de Sun , x86-64 de AMD , PA-RISC de Hewlett-Packard , Alpha de HP (originalmente Digital Equipment Corporation ) y ARM .
El término W^X también se ha aplicado a los permisos de escritura/ejecución del sistema de archivos para mitigar las vulnerabilidades de escritura de archivos (como en la memoria) y la persistencia de los atacantes. [1] La aplicación de restricciones a los permisos de archivos también puede cerrar las brechas en la aplicación de W^X causadas por archivos mapeados en memoria. [2] [3] La prohibición total del uso de código nativo arbitrario también puede mitigar las vulnerabilidades del núcleo y de la CPU no expuestas a través del código existente en la computadora. [4] Un enfoque menos intrusivo es bloquear un archivo durante la duración de cualquier mapeo en la memoria ejecutable, lo que es suficiente para evitar omisiones posteriores a la inspección.
Algunos de los primeros procesadores Intel 64 carecían del bit NX necesario para W^X, pero este apareció en chips posteriores. En procesadores más limitados, como el Intel i386 , W^X requiere el uso del límite del segmento de código CS como una " línea en la arena ", un punto en el espacio de direcciones por encima del cual no se permite la ejecución y se ubican los datos, y por debajo del cual se permite y se ubican las páginas ejecutables. Este esquema se utilizó en Exec Shield . [5]
Los cambios en el enlazador son generalmente necesarios para separar los datos del código (como los trampolines que se necesitan para las funciones de tiempo de ejecución del enlazador y de la biblioteca ). El interruptor que permite la mezcla se suele llamar en sistemas tipo Unix [6]execstack
W^X también puede plantear un problema menor para la compilación justo a tiempo , que implica que un intérprete genere código de máquina sobre la marcha y luego lo ejecute. La solución simple utilizada por la mayoría, incluyendo históricamente a Firefox , implica simplemente hacer que la página sea ejecutable después de que el intérprete haya terminado de escribir el código de máquina, ya sea VirtualProtecten Windows o mprotecten sistemas operativos tipo Unix. La otra solución implica asignar la misma región de memoria a dos páginas, una con RW y la otra con RX. [7] No hay un consenso simple sobre qué solución es más segura: los partidarios de este último enfoque creen que permitir que se ejecute una página que alguna vez ha sido escribible va en contra del objetivo de W^X (existe una política de SELinux para controlar tales operaciones llamada allow_execmod) y que la aleatorización del diseño del espacio de direcciones haría seguro poner ambas páginas en el mismo proceso. Los partidarios del primer enfoque creen que el último enfoque solo es seguro cuando las dos páginas se dan a dos procesos separados, y la comunicación entre procesos sería más costosa que llamar a mprotect.
W^X se implementó por primera vez en OpenBSD 3.3, publicado en mayo de 2003. En 2004, Microsoft introdujo una característica similar llamada DEP ( Data Execution Prevention ) en Windows XP. Hay características similares disponibles para otros sistemas operativos, incluidos los parches PaX y Exec Shield para Linux , y la implementación de PaX de NetBSD . En Red Hat Enterprise Linux (y automáticamente CentOS ) versión 5, o por Linux Kernel 2.6.18-8, SELinux recibió las políticas allow_execmem, allow_execheapy allow_execmodque proporcionan W^X cuando está deshabilitado.
Aunque W^X (o DEP) solo ha protegido programas de espacio de usuario durante la mayor parte de su existencia, en 2012 Microsoft lo extendió al kernel de Windows en las arquitecturas x86 y ARM. [8] A fines de 2014 y principios de 2015, W^X se agregó al kernel de OpenBSD en la arquitectura AMD64. [9] A principios de 2016, W^X se implementó completamente en el kernel AMD64 de NetBSD y parcialmente en el kernel i386.
Las computadoras macOS que funcionan con procesadores Apple Silicon implementan W^X para todos los programas. Las Mac basadas en Intel implementan la política solo para los programas que usan el modo Hardened Runtime del sistema operativo. [10] [11]
A partir de Firefox 46 en 2016 y hasta Firefox 116 en 2023, la máquina virtual de Firefox para JavaScript implementó la política W^X. [7] Esto se revirtió más tarde en algunas plataformas por razones de rendimiento, aunque se mantuvo en otras que aplican W^X para todos los programas. [12]
A partir de .NET 6.0 en 2021, .NET ahora usa W^X. [13]