Компьютерлік қауіпсіздікте орындалатын кеңістікті қорғау

Concept in computer security

In computer security, executable space protection marks memory regions as non executable, such that an attempt to execute machine code in these regions will cause an exception. It makes use of hardware features such as the NX bit (no execute bit), or in some cases software emulation of those features. However, technologies that emulate or supply an NX bit will usually impose a measurable overhead while using a hardware supplied NX bit imposes no measurable overhead. The Burroughs 5000 offered hardware support for executable space protection on its introduction in 1961; that capability remained in its successors until at least 2006. In its implementation of tagged architecture, each word of memory had an associated, hidden tag bit designating it code or data. Thus user programs cannot write or even read a program word, and data words cannot be executed. If an operating system can mark some or all writable regions of memory as non executable, it may be able to prevent the stack and heap memory areas from being executable. This helps to prevent certain buffer overflow exploits from succeeding, particularly those that inject and execute code, such as the Sasser and Blaster worms. These attacks rely on some part of memory, usually the stack, being both writable and executable; if it is not, the attack fails.

As of Android 2.3 and later, architectures which support it have non executable pages by default, including non executable stack and heap.

Initial support for the NX bit, on x86 64 and IA 32 processors that support it, first appeared in FreeBSD CURRENT on June 8, 2004. It has been in FreeBSD releases since the 5.3 release.

The Linux kernel supports the NX bit on x86 64 and IA 32 processors that support it, such as modern 64 bit processors made by AMD, Intel, Transmeta and VIA. The support for this feature in the 64 bit mode on x86 64 CPUs was added in 2004 by Andi Kleen, and later the same year, Ingo Molnár added support for it in 32 bit mode on 64 bit CPUs. These features have been part of the Linux kernel mainline since the release of kernel version 2.6.8 in August 2004. The availability of the NX bit on 32 bit x86 kernels, which may run on both 32 bit x86 CPUs and 64 bit IA 32 compatible CPUs, is significant because a 32 bit x86 kernel would not normally expect the NX bit that an AMD64 or IA 64 supplies; the NX enabler patch assures that these kernels will attempt to use the NX bit if present. Some desktop Linux distributions, such as Fedora, Ubuntu and openSUSE, do not enable the HIGHMEM64 option by default in their default kernels, which is required to gain access to the NX bit in 32 bit mode, because the PAE mode that is required to use the NX bit causes boot failures on pre Pentium Pro (including Pentium MMX) and Celeron M and Pentium M processors without NX support. Other processors that do not support PAE are AMD K6 and earlier, Transmeta Crusoe, VIA C3 and earlier, and Geode GX and LX. VMware Workstation versions older than 4.0, Parallels Workstation versions older than 4.0, and Microsoft Virtual PC and Virtual Server do not support PAE on the guest. Fedora Core 6 and Ubuntu 9.10 and later provide a kernel PAE package which supports PAE and NX. NX memory protection has always been available in Ubuntu for any systems that had the hardware to support it and ran the 64 bit kernel or the 32 bit server kernel. The 32 bit PAE desktop kernel (linux image generic pae) in Ubuntu 9.10 and later, also provides the PAE mode needed for hardware with the NX CPU feature. For systems that lack NX hardware, the 32 bit kernels now provide an approximation of the NX CPU feature via software emulation that can help block many exploits an attacker might run from stack or heap memory. Non execute functionality has also been present for other non x86 processors supporting this functionality for many releases.

macOS for Intel supports the NX bit on all CPUs supported by Apple (from Mac OS X 10.4.4 – the first Intel release – onwards). Mac OS X 10.4 only supported NX stack protection. In Mac OS X 10.5, all 64 bit executables have NX stack and heap; W^X protection. This includes x86 64 (Core 2 or later) and 64 bit PowerPC on the G5 Macs.

As of NetBSD 2.0 and later (December 9, 2004), architectures which support it have non executable stack and heap. Architectures that have per page granularity consist of: alpha, amd64, hppa, i386 (with PAE), powerpc (ibm4xx), sh5, sparc (sun4m, sun4d), sparc64. Architectures that can only support these with region granularity are: i386 (without PAE), other powerpc (such as macppc). Other architectures do not benefit from non executable stack or heap; NetBSD does not by default use any software emulation to offer these features on those architectures.

Solaris has supported globally disabling stack execution on SPARC processors since Solaris 2.6 (1997); in Solaris 9 (2002), support for disabling stack execution on a per executable basis was added.

In Microsoft's Xbox, although the CPU does not have the NX bit, newer versions of the XDK set the code segment limit to the beginning of the kernel's data section (no code should be after this point in normal circumstances). Starting with version 51xx, this change was also implemented into the kernel of new Xboxes. This broke the techniques old exploits used to become a terminate and stay resident program. However, new exploits were quickly released supporting this new kernel version because the fundamental vulnerability in the Xbox kernel was unaffected.

Where code is written and executed at runtime—a JIT compiler is a prominent example—the compiler can potentially be used to produce exploit code (e. g. using JIT Spray) that has been flagged for execution and therefore would not be trapped. Return oriented programming can allow an attacker to execute arbitrary code even when executable space protection is enforced.