Executable space protections PaX

1 executable space protections

1.1 enforced non-executable pages

1.1.1 pageexec
1.1.2 segmexec


1.2 restricted mprotect()
1.3 trampoline emulation

executable space protections

fig. 1 memory segments in program. blue segments code, green data.

the major feature of pax executable space protection offers. these protections take advantage of nx bit on processors prevent execution of arbitrary code. staves off attacks involving code injection or shellcode. on ia-32 cpus there no nx bit, pax can emulate functionality of 1 in various ways.

many operating systems, linux included, take advantage of existing nx functionality in hardware apply proper restrictions memory. fig. 1 shows simple set of memory segments in program 1 loaded library; green segments data , blue code. in normal cases, address space on amd64 , other such processors default more fig. 1, defined data , code. unfortunately, linux default not prohibit application changing of memory protections; program may create data-code confusion, marking areas of code writable , areas of data executable. pax prevents such changes, guaranteeing restrictive default set suitable typical operation.

when executable space protections enabled, including mprotect() restrictions, pax guarantees no memory mappings marked in way in may executed program code after has been possible alter them original state. effect of becomes impossible execute memory during , after has been possible write it, until memory destroyed; , thus, code cannot injected application, malicious or otherwise, internal or external source.

the fact programs cannot execute data originated program code poses impassable problem applications need generate code @ runtime basic function, such just-in-time compilers java; however, programs have difficulty functioning under these restrictions can debugged programmer , fixed not rely on functionality. need functionality, or haven t yet been fixed, program s executable file can marked system administrator not have these restrictions applied it.

the pax team had make design decisions how handle mmap() system call. function used either map shared memory, or load shared libraries. because of this, needs supply writable or executable ram, depending on conditions used under.

the current implementation of pax supplies writable anonymous memory mappings default; file backed memory mappings made writable if mmap() call specifies write permission. mmap() function never return mappings both writable , executable, if permissions explicitly requested in call.

enforced non-executable pages

by default, linux not supply secure usage of non-executable memory pages, via nx bit. furthermore, architectures not explicitly supply way of marking memory pages non-executable. pax supplies policy take advantage of non-executable pages in secure way possible.

in addition, if cpu not provide explicit nx bit, pax can emulate (supply) nx bit 1 of several methods. degrades performance of system, increases security greatly. furthermore, performance loss in methods may low enough ignored.

pageexec

pageexec uses or emulates nx bit. on processors not support hardware nx, each page given emulated nx bit. method used based on architecture of cpu. if hardware nx bit available, pageexec use instead of emulating one, incurring no performance costs.

on ia-32 architectures, nx bit emulation done changing permission level of non-executable pages. supervisor bit overloaded represent nx. causes protection fault when access occurs page , not yet cached in translation lookaside buffer. in case, memory management unit alerts operating system; on ia-32, mmu typically has separate tlb caches execution (itlb) , read/write (dtlb), fault allows linux , pax determine whether program trying execute page code. if itlb fault caught, process terminated; otherwise linux forces dtlb load allowed, , execution continues normal.

pageexec has advantage of not dividing memory address space in half; tasks still each 3 gb virtual ramspace rather 1.5/1.5 split. however, emulation, slower segmexec , caused severe performance detriment in cases.

since may 2004, newer pageexec code ia-32 in pax tracks highest executable page in virtual memory, , marks higher pages user pages. allows data pages above limit—such stack—to handled normal, no performance loss. below area still handled before. change similar exec shield nx implementation, , openbsd w^x implementation; except pax uses supervisor bit overloading method handle nx pages in code segment well.

segmexec

segmexec emulates functionality of nx bit on ia-32 (x86) cpus splitting address space in half , mirroring code mappings across address space. when there instruction fetch, fetch translated across split. if code not mapped there, program killed.

segmexec cuts task s virtual memory space in half. under normal circumstances, programs vm space 3gib wide, has physical memory mapped it. under segmexec, becomes 1.5/1.5 gib split, top half used mirroring. despite this, increase performance if emulation must done on ia-32 (x86) architectures. mapping in upper , lower half of memory space same physical memory page, , not double ram usage.

restricted mprotect()

pax supposed guarantee no ram both writable , executable. 1 function, mprotect() function, changes permissions on memory area. single unix specification defines mprotect() following note in description:

if implementation cannot support combination of access types specified prot, call mprotect() shall fail.

the pax implementation not allow memory page have permissions prot_write , prot_exec both enabled when mprotect() restrictions enabled task; call mprotect() set both (prot_write | prot_exec) @ same time fail due eaccess (permission denied). guarantees pages not become both writable , executable, , fertile ground simple code injection attacks.

similar failure occurs if mprotect(...|prot_exec) occurs on page not have prot_exec restriction on. failure here justified; if prot_write page has code injected it, , made prot_exec, later retriggering of exploit allowing code injection allow code executed. without restriction, three-step exploit possible: inject code, ret2libc::ret2mprotect(), execute code.

with mprotect() restrictions enabled, program can no longer violate non-executable pages policy pax sets down on memory allocations; thus, restricted mprotect() considered strict enforcement of security policy, whereas enforced non-executable pages without these restrictions considered looser form of enforcement.

trampoline emulation

trampolines implemented gcc small pieces of code generated @ runtime on stack. thus, require executing memory on stack, triggers pax kill program.

because trampolines runtime generated code, trigger pax , cause program using them killed. pax capable of identifying setup of trampolines , allowing execution. is, however, considered produce situation of weakened security.