W^X (W xr X) is a security policy used in operating systems and software frameworks that enforces executable space protection. It ensures each memory page in a program's virtual address space is either writable or executable, but not both, preventing malicious code execution from writable memory. Introduced in 2003 for Unix-like systems, W^X is also used in multi-platform environments like .NET, with similar protections such as DEP in Windows. Typically controlled via the mprotect system call on supported processor architectures like x86-64 and ARM, W^X can also apply at the file system level to mitigate write-execute vulnerabilities.
Compatibility
Some early Intel 64 processors lacked the NX bit required for W^X, but this appeared in later chips. On more limited processors such as the Intel i386, W^X requires using the CS code segment limit as a "line in the sand", a point in the address space above which execution is not permitted and data is located, and below which it is allowed and executable pages are placed. This scheme was used in Exec Shield.6
Linker changes are generally required to separate data from code (such as trampolines that are needed for linker and library runtime functions). The switch allowing mixing is usually called execstack on Unix-like systems7
W^X can also pose a minor problem for just-in-time compilation, which involves an interpreter generating machine code on the fly and then running it. The simple solution used by most, historically including Firefox, involves just making the page executable after the interpreter is done writing machine code, using VirtualProtect on Windows or mprotect on Unix-like operating systems. The other solution involves mapping the same region of memory to two pages, one with RW and the other with RX.8 There is no simple consensus on which solution is safer: supporters of the latter approach believe allowing a page that has ever been writable to be executed defeats the point of W^X (there exists an SELinux policy to control such operations called allow_execmod) and that address space layout randomization would make it safe to put both pages in the same process. Supporters of the former approach believe that the latter approach is only safe when the two pages are given to two separate processes, and inter-process communication would be costlier than calling mprotect.
History
W^X was first implemented in OpenBSD 3.3, released May 2003. In 2004, Microsoft introduced a similar feature called DEP (Data Execution Prevention) in Windows XP. Similar features are available for other operating systems, including the PaX and Exec Shield patches for Linux, and NetBSD's implementation of PaX. In Red Hat Enterprise Linux (and automatically CentOS) version 5, or by Linux Kernel 2.6.18-8, SELinux received the allow_execmem, allow_execheap, and allow_execmod policies that provide W^X when disabled.
Although W^X (or DEP) has only protected userland programs for most of its existence, in 2012 Microsoft extended it to the Windows kernel on the x86 and ARM architectures.9 In late 2014 and early 2015, W^X was added in the OpenBSD kernel on the AMD64 architecture.10 In early 2016, W^X was fully implemented on NetBSD's AMD64 kernel and partially on the i386 kernel.
macOS computers running on Apple silicon processors enforce W^X for all programs. Intel-based Macs enforce the policy only for programs that use the OS's Hardened Runtime mode.1112
Starting with Firefox 46 in 2016 and ending with Firefox 116 in 2023, Firefox's virtual machine for JavaScript implemented the W^X policy.13 This was later rolled back on some platforms for performance reasons, though remained in others which enforce W^X for all programs.14
Starting with .NET 6.0 in 2021, .NET now uses W^X.15
External links
- OpenBSD-3.3 announcement, public release of W^X
- Slides from a presentation by OpenBSD lead developer Theo de Raadt covering W^X
References
"What's new in .NET 6". docs.microsoft.com. Microsoft. Retrieved November 9, 2021. https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-6#security ↩
"Enforce execve() restrictions for API > 28". https://android-review.googlesource.com/c/platform/system/sepolicy/+/804149 ↩
"Zack's Kernel News". https://www.linux-magazine.com/Issues/2017/204/Kernel-News ↩
"S.A.R.A. a new stacked LSM". https://lore.kernel.org/patchwork/cover/798675/#1002174 ↩
"Hardening the Linux Kernel (series 2.0.x)". http://phrack.org/issues/52/6.html ↩
"i386 W^X". April 17, 2003. Retrieved June 19, 2014. https://marc.info/?l=openbsd-misc&m=105056000801065 ↩
execstack(8) – Linux System Administration Manual. https://www.mankier.com/8/execstack ↩
"W^X JIT-code enabled in Firefox". Retrieved April 29, 2016. http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox ↩
"Exploit mitigation improvements in Win8". https://www.blackhat.com/html/bh-us-12/bh-us-12-briefings.html#Miller2 ↩
"W^X protection for the AMD64 kernel". https://marc.info/?l=openbsd-tech&m=142120787308107&w=2 ↩
"Porting Just-In-Time Compilers to Apple Silicon". developer.apple.com. Retrieved April 17, 2022. https://developer.apple.com/documentation/apple-silicon/porting-just-in-time-compilers-to-apple-silicon ↩
"ARM Macs FAQ". SecureMac. July 17, 2020. Retrieved April 17, 2022. https://www.securemac.com/news/arm-macs-faq ↩
"W^X JIT-code enabled in Firefox". Retrieved April 29, 2016. http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox ↩
"1835876 - Consider disabling code memory protection in the content process". bugzilla.mozilla.org. Mozilla. Retrieved July 1, 2024. https://bugzilla.mozilla.org/show_bug.cgi?id=1835876 ↩
"What's new in .NET 6". docs.microsoft.com. Microsoft. Retrieved November 9, 2021. https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-6#security ↩