Features PaX

1 features

1.1 executable space protections

1.1.1 enforced non-executable pages

1.1.1.1 pageexec
1.1.1.2 segmexec


1.1.2 restricted mprotect()
1.1.3 trampoline emulation


1.2 address space layout randomization

1.2.1 randomized stack base
1.2.2 randomized mmap() base
1.2.3 randomized et_exec base


1.3 binary markings

features

pax offers executable space protection, using (or emulating in operating system software) functionality of nx bit (i.e., built-in cpu , mmu support memory contents execution privilege tagging). provides address space layout randomization defeat ret2libc attacks , other attacks relying on known structure of program s virtual memory.

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.

address space layout randomization

address space layout randomization, or aslr, technique of countering arbitrary execution of code, or ret2libc attacks. these attacks involve executing existing code out of order intended programmer.

fig. 2 distance between various areas of memory randomly selected, indicated half-head arrow. example, gap between stack , top of memory random in magnitude.

aslr provided in pax shuffles stack base , heap base around in virtual memory when enabled. optionally randomizes mmap() base , executable base of programs. substantially lowers probability of successful attack requiring attacking code guess locations of these areas.

fig. 2 shows qualitative views of process address spaces address space layout randomization. half-head arrows indicate random gap between various areas of virtual memory. @ point when kernel initializes process, length of these arrows can considered grow longer or shorter template independent of each other.

during course of program s life, heap, called data segment or .bss, grow up; heap expands towards highest memory address available. conversely, stack grows down, towards lowest memory address, 0.

it extremely uncommon program require large percent of address space either of these. when program libraries dynamically loaded @ start of program operating system, placed before heap; however, there cases program load other libraries, such commonly referred plugins, during run. operating system or program must choose acceptable offset place these libraries at.

pax leaves portion of addresses, msbs, out of randomization calculations. helps assure stack , heap placed not collide each other, , libraries placed stack , heap not collide them.

the effect of randomization depends on cpu. 32-bit cpus have 32 bits of virtual address space, allowing access 4gib of memory. because linux uses top 1 gb kernel, shortened 3gib. segmexec supplies split down middle of 3gib address space, restricting randomization down 1.5gib. pages 4kib in size, , randomizations page aligned. top 4 msbs discarded in randomization, heap exists @ beginning , stack @ end of program. computes down having stack , heap exist @ 1 of several million positions (23 , 24 bit randomization), , libraries existing in of approximately 65,000 positions.

on 64-bit cpus, virtual address space supplied mmu may larger, allowing access more memory. randomization more entropic in such situations, further reducing probability of successful attack in lack of information leak.

randomized stack base

pax randomly offsets base of stack in increments of 16 bytes, combining random placement of actual virtual memory segment sub-page stack gap. total magnitude of randomization depends on size of virtual memory space; example, stack base somewhere in 256mib range on 32-bit architectures, giving 16 million possible positions or 24 bits of entropy.

fig. 3 stack smashing attack. target of attack keeps same address; payload moves stack.

the randomization of stack base has effect on payload delivery during shellcode , return-to-libc attacks. shellcode attacks modify return pointer field address of payload; while return-to-libc attacks modify stack frame pointer. in either case, probability of success diminished significantly; position of stack unpredictable, , missing payload causes program crash.

in case of shellcode, series of instructions called nop slide or nop sled can prepended payload. add 1 more success case per 16 bytes of nop slide. 16 bytes of nop slide increase success rate 1/16m 2/16m; 128 bytes of nop slide increase 9/16m. increase in success rate directly proportional size of nop slide; doubling length of given nop slide doubles chances of successful attack.

return-to-libc attacks not use code, rather inject fixed width stack frames. because of this, stack frames have repeat aligned 16 bytes. stack frame bigger this, giving repeated stack frame payloads of same length given nop sled less of impact on success rate of attacks.

randomized mmap() base

in posix systems, mmap() system call allows memory allocated @ offsets specified process or selected kernel. can anonymous memory nothing in it; or file backed memory mappings, simulate portion of file or copy of said portion in memory @ point. program libraries loaded in using mmap() map code , data private—the files copied memory if changed, rather rewritten on disk.

any mmap() call may or may not specify offset in virtual memory allocate mapping at. if offset not specified, operating system select one. linux calculating offset in predictable manner, starting predefined virtual address called mmap() base. because of this, every run of process loads initial libraries such c standard library or libc in same place.

when randomized mmap() base enabled, pax randomly shifts mmap() base, affecting positioning of libraries , other non-specific mmap() calls. causes dynamically linked code, i.e. shared objects, mapped @ different, randomly selected offset every time. attackers requiring function in library must guess library loaded in virtual memory space call it. makes return-to-libc attacks difficult; although shellcode injections can still address of function in global offset table.

pax not change load order of libraries. means if attacker knows address of 1 library, can derive locations of other libraries; however, notable there more serious problems if attacker can derive location of library in first place, , randomization not that. further, typical attacks require finding 1 library or function; other interesting elements such heap , stack separately randomized , not derivable mmap() base.

when et_dyn executables—that is, executables compiled position independent code in same way shared libraries—are loaded, base randomly chosen, mmap()ed ram regular shared objects.

when combining non-executable stack mmap() base randomization, difficulty in exploiting bugs protected against pax increased due forced use of return-to-libc attacks. on 32-bit systems, amounts 16 orders of magnitude; is, chances of success recursively halved 16 times. combined stack randomization, effect can quite astounding; if every person in world (assuming 6 billion total) attacks system once, 1 2 should succeed on 32-bit system. 64-bit systems of course benefit greater randomization.

randomized et_exec base

pax able map non-position-independent code randomly ram; however, poses few problems. first, incurs performance overhead. second, on rare occasions causes false alarms, bringing pax kill process no reason. recommended executables compiled et_dyn, 100% position independent code.

the randomization of executable load base et_exec fixed position executables affected security flaw in vm mirroring code in pax. hadn t upgraded, flaw worked around disabling segmexec nx bit emulation , randexec randomization of executable base.

binary markings

pax allows executable files in executable , linkable format marked reduced restrictions via chpax , paxctl tools. these markings exist in elf header, , both filesystem independent , part of file object itself. means markings retained through packaging, copying, archiving, encrypting, , moving of objects. chpax tool deprecated in favor of paxctl.

pax allows individual markings both pageexec , segmexec; randomizing mmap(), stack, , heap base; randomizing executable base et_exec binaries; restricting mprotect(); , emulating trampolines.

in case of chpax, tools such strip may lose markings; using paxctl set pt_pax_flags reliable method. paxctl tool uses new elf program header created pax flags. these markings can explicitly on, off, or unset. when unset, decision on setting use made pax code in kernel, , influenced system-wide pax softmode setting.