Software Defense Mechanisms: PaX and the future

1. Software Defense Mechanisms: PaX and the future past continuous

2. Who am I? • NOT Brad Spengler – I have decent ears • Tiago Assumpção <tiago@assumpcao.org> • NOT an academic • An undisciplined curious person with lots of energy to be spent on whatever is valued by his self

3. Who am I? (cont.) • NOT a PaX developer… however… • Have had delightful discussions with PaX Team about whatever blows your hair back • Have been improving the project [2] • Have been questioning the project [3]

4. In praise of hacking • “The speculations of Thales, Anaximander, and Anaximenes are to be regarded as scientific hypotheses (...) The questions they asked were good questions, and their vigour inspired subsequent investigators.” RUSSELL, Bertrand; History of Western Philosophy - 1946. p. 37

5. What is PaX? • Quite simply: the greatest advance in system security in over a decade that you’ve never heard of • Less simply: It provides non-executable memory pages and full address space layout randomization (ASLR) for a wide variety of architectures. – Brad “grears” Spengler

6. What is PaX? • Linux kernel patch • Free-software & open-source is good for the general researcher • Universal solutions: concepts easily extentend to any modern platform

7. Why is PaX? • Given a vector: • Payload (code/data) injection • Context (memory/registers/etc.) manipulation • Intentional Control Flow modification

8. Outline • PaX • SEGMEXEC • PAGEEXEC • KERNEXEC • ASLR • RANDMMAP • RANDKSTACK • PIE • UDEREF

9. Outline (cont.) • PaX’ Facts • Past Continuous • Control Flow Verification • KERNSEAL

10. PaX - SEGMEXEC • SEGMEXEC is PaX’s implementation of per-page non-executable user pages using the segmentation logic of IA-32 (Intel x86 architecture) and virtual memory area mirroring (developed by PaX).

11. PaX – SEGMEXEC (cont.) • The segmentation logic is fairly straightforward: • Data Segment (DS) • Code Segment (CS) • There exist these two segments for user pages as well as kernel pages. • PaX splits the address space down the middle: the bottom half for data, the top for code. • Segmentation is a “window” into the address space • No performance hit

12. PaX – SEGMEXEC (cont.) Without SEGMEXEC With SEGMEXEC User Code & Data Segments 3GB User Code Segment 1.5GB User Data Segment 1.5GB

13. PaX – SEGMEXEC (cont.) • PaX’s VMA mirroring involves duplicating every executable page in the lower half of the address space into the upper half. • Instruction fetch attempts at addresses located in the data segment that don’t have any code located at its mirrored address will cause a page fault. PaX handles this page fault and kills the task.

14. PaX – SEGMEXEC (cont.) 08048000-0804c000 r-xp /home/bradly/cat 0804c000-0804d000 rw-p /home/bradly/cat 0804d000-08073000 rw-p 40000000-40014000 r-xp /lib/ld-2.3.2.so 40014000-40015000 rw-p /lib/ld-2.3.2.so 40015000-40016000 rw-p 4001e000-40145000 r-xp /lib/libc-2.3.2.so 40145000-4014a000 rw-p /lib/libc-2.3.2.so 4014a000-4014c000 rw-p 4014c000-402d1000 r--p /usr/lib/locale/locale-archive bfffe000-c0000000 rw-p Without SEGMEXEC 08048000-0804c000 r-xp /home/bradly/cat 0804c000-0804d000 rw-p /home/bradly/cat 0804d000-08079000 rw-p 20000000-20014000 r-xp /lib/ld-2.3.2.so 20014000-20015000 rw-p /lib/ld-2.3.2.so 20015000-20016000 rw-p 2001e000-20145000 r-xp /lib/libc-2.3.2.so 20145000-2014a000 rw-p /lib/libc-2.3.2.so 2014a000-2014c000 rw-p 2014c000-202d1000 r--p /usr/lib/locale/locale-archive 5ffff000-60000000 rw-p 68048000-6804c000 r-xp /home/bradly/cat 80000000-80014000 r-xp /lib/ld-2.3.2.so 8001e000-80145000 r-xp /lib/libc-2.3.2.so With SEGMEXEC

15. PaX – SEGMEXEC (cont.) Segmentation logic translates 0x08049000 into 0x68049000 Does 0x68049000 belong to any mapping? Instruction fetch attempt at 0x08049000 YES Success NO Violation, process is terminated

16. PaX - PAGEEXEC • PAGEEXEC was PaX’s first implementation of non-executable pages. • Because of SEGMEXEC, it’s not used anymore on x86 (so I won’t discuss the implementation). • Platforms which support the executable bit in hardware are implemented under PAGEEXEC (currently alpha, ppc, parisc, sparc, sparc64, amd64, and ia64)

17. PaX - KERNEXEC • KERNEXEC is PaX’s implementation of proper page protection in the kernel • ‘const’ finally means read only in the kernel • Read-only system call table • Read-only interrupt descriptor table (IDT) • Read-only global descriptor table (GDT) • Data is non-executable • Uses the same concept of segmentation as SEGMEXEC • Cannot co-exist with module support (currently)

18. PaX - ASLR • Full ASLR randomizes the locations of the following memory objects: • Executable image • Brk-managed heap • Library images • Mmap-managed heap • User space stack • Kernel space stack

19. PaX – ASLR (cont.) • Notes on amount of randomization: • The following values are for 32bit architectures. They are larger on 64bit architectures, though not twice as large (since they generally don’t use 64 bits for the address space). • Stack – 24 bits (28 bits for argument/environment pages) • Mmap – 16 bits • Executable – 16 bits • Heap – 12 bits (or 24 bits if executable is randomized also)

20. PaX – ASLR (cont.) • The randomizations applied to each memory region are independent of each other • Because PaX guarantees no arbitrary code execution, exploits will most likely need to access different memory regions. • So, if the exploit needs access to libraries and the stack, the bits that must be guessed are the sum of the two regions: 40 bits (or 44). The chance of such an attack succeeding while depending on hard coded addresses is effectively zero.

21. PaX – ASLR (cont.) 08048000-0804c000 r-xp /home/bradly/cat 0804c000-0804d000 rw-p /home/bradly/cat 0804d000-08078000 rw-p 4edaa000-4edbe000 r-xp /lib/ld-2.3.2.so 4edbe000-4edbf000 rw-p /lib/ld-2.3.2.so 4edbf000-4edc0000 rw-p 4edc8000-4eeef000 r-xp /lib/libc-2.3.2.so 4eeef000-4eef4000 rw-p /lib/libc-2.3.2.so 4eef4000-4eef6000 rw-p 4eef6000-4f07b000 r--p /usr/lib/locale/locale-archive bf3dc000-bf3dd000 rw-p Two runs of a binary with stack, mmap, and heap randomization 08048000-0804c000 r-xp /home/bradly/cat 0804c000-0804d000 rw-p /home/bradly/cat 0804d000-08070000 rw-p 43d8c000-43da0000 r-xp /lib/ld-2.3.2.so 43da0000-43da1000 rw-p /lib/ld-2.3.2.so 43da1000-43da2000 rw-p 43daa000-43ed1000 r-xp /lib/libc-2.3.2.so 43ed1000-43ed6000 rw-p /lib/libc-2.3.2.so 43ed6000-43ed8000 rw-p 43ed8000-4405d000 r--p /usr/lib/locale/locale-archive b54f9000-b54fa000 rw-p

22. PaX – ASLR (cont.) • RANDKSTACK • Randomizes the kernel’s stack • Randomized on each system call, so info-leaking the randomization is useless • Randomizes 5 bits of the stack. Brute forcing generally shouldn’t be possible, as each attempt will most likely crash the kernel.

23. PaX – ASLR (cont.) • PIE • Special type of ELF binary (the same used for shared libraries) • Position independent code (PIC) • Allows for relocation of the binary at a random location • Needed to achieve Full ASLR • Requires a recompile and re-link of applications

24. PaX – Dangling Pointers • “Dangling pointers and wild pointers in computer programming are pointers that do not point to a valid object of the appropriate type, or to a distinguished null pointer value in languages which support this” Wikipedia

25. PaX – Dangling Pointers (cont.) • Most i386 OSs don't separate the userland virtual address space from that of the kernel. • Linux 2.6 has per-cpu GDTs; LDTs are untouched • BSDs creates flat per-process LDTs • Windows creates flat per-process LDTs

26. PaX – Dangling Pointers (cont.) • Thence, whenever userland can make the kernel (unexpectedly) dereference a pointer within its range of control, it holds ability to controlling the data (and, possibly, code) flow of the kernel by virtue of providing the attack elements in its own address space. • Real-life [4]

27. PaX – UDEREF Without UDEREF With UDEREF Kernel & User Segments 4GB Kernel Segments 1GB User Segments 3GB

28. PaX – UDEREF (cont.) • Segment selectors are properly set • Few modifications are done regarding user/kernel, kernel/kernel system calls

29. PaX 24/28 bit stack randomization 16 bit mmap randomization Completely implemented in the kernel. Can be implemented transparently and retain binary compatibility with all distributions. Facts

30. PaX Cuts usable address space in half (though this can be changed if it becomes a problem) Support for non-executable and read-only kernel pages on i386 Facts (cont.)

31. PaX Per-system call kernel stack randomization Brk-managed heap randomization Ability to enable/disable all features on a per binary basis Annihilates the possibility of exploiting kernel dereferencing pointer vulnerabilities Facts (cont.)

32. PaX Supports the same user space features on i386, alpha, ppc, parisc, sparc, sparc64, amd64, and ia64 Supports a per-page implementation of non-executable pages on ppc Facts (cont.)

33. PaX – Past Continuous • Control Flow Verification • Basic blocks • A basic block is a sequence of statements that is always entered at the beginning and exited at the end, that is: • The first statement is a LABEL • The last statement is a JUMP or a CJUMP • There are no other LABELs, JUMPs, or JUMPs APPEL, Andrew W.; Modern Compiler Implementation in ML- 2004. p. 180

34. PaX – Past Continuous • Control Flow Verification • Control Flow Graph (CFG) • “In computer science, a control flow graph (CFG) is a representation, using graph notation, of all paths that might be traversed through a program during its execution. Each node in the graph represents a basic block, (…)” Wikipedia

35. PaX – Past Continuous • Control Flow Verification

36. PaX – Past Continuous • Control Flow Verification • Call graphs • “A call graph (also known as a call multigraph) is a directed graph that represents calling relationship among subroutines in a computer program” Wikipedia

37. PaX – Past Continuous • Control Flow Verification

38. PaX – Past Continuous • Control Flow Verification • Static analysis • Build call graph for program P • Build set S of callers • Build set Q of callees • Build set R of relationships between S and Q, creating magic value for each

39. PaX – Past Continuous • Control Flow Verification • Code generation • Create proper prologues for every member of S • Create proper epilogues for every member of Q • Magic Values • Hard to predict by exhaustive search values kept within safe memory regions, they are verified in run-time

40. PaX – Past Continuous • Control Flow Verification callee epilogue: mov register,[esp] cmp [register+1],MAGIC jnz .1 retn .1: jmp esp caller: call callee test eax,MAGIC

41. PaX – Past Continuous • Control Flow Verification: Nondeterminism • Branch tables: run-time environment • OO virtual methods and function pointers

42. PaX – Past Continuous • Control Flow Verification • GOT entries • Made read-only by tweaking the static and the dynamic linker • .ctors/.dtors • Made read-only by modifying the link-editor script

43. PaX – Past Continuous • Control Flow Verification • Are of a dynamic nature • atexit() handlers • malloc() callbacks • linuxthread callbacks (atfork() handlers)

44. PaX – Past Continuous (cont.) • Control Flow Verification: Results • Breaks my attack [3] – brief explanation? – and anything that rely on the following premisses • execute existing code out of original program order • execute existing code in original program order with arbitrary data

45. PaX – Past Continuous (cont.) • Control Flow Verification: Results • Opens a wide range of possibilities for improving systemic security • Call graph trust relationship ensures that (in most cases) all control flow (including intra-procedural) can’t be broken with a very low performance impact • Call graph trust relationship allows data integrity verification (KERNSEAL)

46. PaX – Past Continuous • KERNSEAL • Liveness Analysis • “We say a variable is live if it holds a value that may be needed in the future, so this analysis is called livenessanalysis” APPEL, Andrew W.; Modern Compiler Implementation in ML- 2004. p. 211

47. PaX – Past Continuous • KERNSEAL • The set of live variables at line L2 is {b, c}, but the set of live variables at line L1 is only {b} since variable c is updated in line 2. The value of variable a is never used, so the variable is never live. • L1: b := 3; • L2: c := 5; • L3: a := b + c; • goto L1;

48. PaX – Past Continuous • KERNSEAL • Liveness Analysis: Dataflow equations • “Liveness of variables ‘flows’ around the edges of the control-flow graph; determining the live range of each variable is na example of a dataflow problem” APPEL, Andrew W.; Modern Compiler Implementation in ML- 2004. p. 213

49. PaX – Past Continuous • KERNSEAL • Liveness Analysis: Terminology • Out-edges: nodes leading to successor nodes • In-edges: nodes coming from predecesor nodes • pred[n], holding the set of predecessors of node n • succ[n], holding the set of successors of node n

50. PaX – Past Continuous • KERNSEAL • Liveness Analysis: Terminology • Uses: the set of variables in use at a given node • Defs: the set of variables assigned at a given node