W^X

Source: Wikipedia, the free encyclopedia.

W^X ("write xor execute", pronounced W

executable space protection
, controlled via the mprotect system call.

W^X is relatively simple on

ARM
.

The term W^X has also been applied to file system write/execute permissions to mitigate file write vulnerabilities (as with in memory) and attacker persistence.[1] Enforcing restrictions on file permissions can also close gaps in W^X enforcement caused by memory mapped files.[2][3] Outright forbidding the usage of arbitrary native code can also mitigate kernel and CPU vulnerabilities not exposed via the existing code on the computer.[4] A less intrusive approach is to lock a file for the duration of any mapping into executable memory, which suffices to prevent post-inspection bypasses.

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.[5]

runtime functions). The switch allowing mixing is usually called execstack on Unix-like systems[6]

W^X can also pose a minor problem for

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

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.[8] In late 2014 and early 2015, W^X was added in the OpenBSD kernel on the AMD64 architecture.[9] 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.[10][11]

Starting with Firefox 46 in 2016, Firefox's virtual machine for JavaScript also implements the W^X policy.[7]

Starting with .NET 6.0 in 2021, .NET now uses W^X.[12]

References

  1. ^ "Enforce execve() restrictions for API > 28".
  2. ^ "Zack's Kernel News".
  3. ^ "S.A.R.A. a new stacked LSM".
  4. ^ "Hardening the Linux Kernel (series 2.0.x)".
  5. ^ "i386 W^X". April 17, 2003. Retrieved June 19, 2014.
  6. ^ execstack(8) – Linux System Administration Manual
  7. ^ a b "W^X JIT-code enabled in Firefox". Retrieved April 29, 2016.
  8. ^ "Exploit mitigation improvements in Win8".
  9. ^ "W^X protection for the AMD64 kernel".
  10. ^ "Porting Just-In-Time Compilers to Apple Silicon". developer.apple.com. Retrieved April 17, 2022.
  11. ^ Inc, SecureMac (July 17, 2020). "ARM Macs FAQ". SecureMac. Retrieved April 17, 2022. {{cite web}}: |last= has generic name (help)
  12. ^ "What's new in .NET 6". docs.microsoft.com. Microsoft. Retrieved November 9, 2021.

External links

Retrieved from "https://en.wikipedia.org/w/index.php?title=W%5EX&oldid=1209781551"
This page is based on the copyrighted Wikipedia article: W^X. Articles is available under the CC BY-SA 3.0 license; additional terms may apply.Privacy Policy