W^X ("escribir xor ejecutar", 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 la memoria mediante la cual cada página en el espacio de direcciones de un proceso o núcleo puede ser escribible o ejecutable , pero no ambas. Sin dicha protección, un programa puede escribir (como datos "W") instrucciones de la CPU en un área de memoria destinada a datos y luego ejecutar (como ejecutable "X"; o lectura y ejecución "RX") esas instrucciones. Esto puede resultar 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 mediante la llamada al sistema.mprotect
W^X es relativamente simple en arquitecturas de procesador que admiten permisos de página detallados, como SPARC y SPARC64 de Sun , x86-64 de AMD , PA-RISC de Hewlett-Packard , HP (originalmente Digital Equipment Corporation ) Alfa y BRAZO .
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] Hacer cumplir restricciones en los permisos de archivos también puede cerrar las brechas en la aplicación de W^X causadas por archivos asignados en memoria. [2] [3] Prohibir rotundamente el uso de código nativo arbitrario también puede mitigar las vulnerabilidades del kernel 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 mientras dure 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 apareció en chips posteriores. En procesadores más limitados como el Intel i386 , W^X requiere usar el 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 debajo del cual no se permite la ejecución. está permitido y se colocan páginas ejecutables. Este esquema se utilizó en Exec Shield . [5]
Generalmente se requieren cambios en el vinculador para separar los datos del código (como los trampolines que se necesitan para las funciones de tiempo de ejecución del vinculador y 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, incluido 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, usándolo 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 otra con RX. [7] No existe 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 en la que alguna vez se ha podido escribir anula el objetivo de W^X (existe una política de SELinux para controlar tales operaciones llamada allow_execmod) y esa aleatorización del diseño del espacio de direcciones haría que fuera seguro colocar ambas páginas en el mismo proceso. Los partidarios del primer enfoque creen que el segundo solo es seguro cuando las dos páginas se asignan a dos procesos separados, y la comunicación entre procesos sería más costosa que llamar mprotect.
W^X se implementó por primera vez en OpenBSD 3.3, lanzado en mayo de 2003. En 2004, Microsoft introdujo una característica similar llamada DEP ( Prevención de ejecución de datos ) 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 en NetBSD . En Red Hat Enterprise Linux (y automáticamente CentOS ) versión 5, o en el Kernel de Linux 2.6.18-8, SELinux recibió las allow_execmempolíticas allow_execheap, y allow_execmodque proporcionan W^X cuando está deshabilitado.
Aunque W^X (o DEP) solo ha protegido programas 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 finales de 2014 y principios de 2015, se agregó W^X en el 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 se ejecutan en procesadores Apple Silicon aplican W^X para todos los programas. Las Mac basadas en Intel aplican la política sólo para los programas que utilizan el modo de tiempo de ejecución reforzado del sistema operativo. [10] [11]
A partir de Firefox 46 en 2016, la máquina virtual de Firefox para JavaScript también implementa la política W^X. [7]
A partir de .NET 6.0 en 2021, .NET ahora usa W^X. [12]
{{cite web}}: |last=tiene nombre genérico ( ayuda )