Patras Heap Massacre

FOSSCOMM 2011 (with Chariton Karamitas)

Transcript

1. FOSSCOMM 2011 Chariton Karamitas <huku@census-labs.com> Patroklos Argyroudis <argp@census-labs.com> Patras Heap Massacre
2. WHO ARE THOSE GUYS?  Computer security researchers  Main organizers of 0x375!  http://www.twitter.com/x05x37  Phrack authors :-)  Exploiting UMA, FreeBSD’s kernel memory allocator (argp)  Yet another free() exploitation technique (huku)  Census (www.census-labs.com)  IT security research, development and services  Independent and privately funded 2 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
3. THE VENERABLE STACK OVERFLOW 3 argp & huku - FOSSCOMM 2011 Patras Heap Massacre Images from http://en.wikipedia.org/wiki/Stack_buffer_overflow
4. THE VENERABLE STACK OVERFLOW  Easy to detect, easy to exploit  Programmers are getting smarter → Stack overflows are getting extinct   Stack is only the one side of the coin!  What about other memory regions?  We no longer live in the ‘90s   Not sure if this is good or bad 4 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
5. WHAT IS THE HEAP?  Heap memory is unrelated to Heap data structures.  Several authors began about 1975 to call the pool of available memory a “heap.” – Donald Knuth  Unlike stacks, there’s no hardware (CPU) support for heaps.  Heap managers have to organize memory by themselves  Heap managers are 100% implemented in software (usually in C)  …and, of course, they use their own housekeeping information (usually inline)  …and this is where the problems begin :-) 5 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
6. WHY USE A HEAP?  Not all object sizes and needs are known at compile time  If they were, we would only need static memory  Need to split a large memory area into small blocks in a dynamic fashion  …and a userspace/kernel space API for doing so  Preferably one that abstracts the internals.  Advantages  No/reduced fragmentation of the available memory  Increased performance 6 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
7. MEMORY CORRUPTION MITIGATIONS  Canaries  DEP  ASLR Memory corruption mitigations
8. MEMORY CORRUPTION MITIGATIONS - CANARIES  Heap and Stack memory are protected using canaries  Fixed  Terminator  Random (or even XOR’ed) 8 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
9. MEMORY CORRUPTION MITIGATIONS - DEP  DEP = Data Execution Prevention  W^X primitive  Usually DEP = noexec stack + noexec heap  Example on Linux:  $ cat /proc/self/maps 9 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
10. MEMORY CORRUPTION MITIGATIONS - ASLR  ASLR = Address Space Layout Randomization  Limited entropy – Usually only the first few bits of an address are randomized  Example on Linux:  $ cat /proc/self/maps 10 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
11. USERSPACE ALLOCATORS  Linux  FreeBSD  Microsoft Windows Heap internals
13. DLMALLOC ARCHITECTURE – LOGIC AND LAYOUT 13 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
14. DLMALLOC ARCHITECTURE – ALLOCATION OVERVIEW 14 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
15. DLMALLOC ARCHITECTURE – DEALLOCATION OVERVIEW 15 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
17. JEMALLOC ARCHITECTURE – LOGIC AND LAYOUT 17 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
18. JEMALLOC ARCHITECTURE – ALLOCATION OVERVIEW 18 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
19. JEMALLOC ARCHITECTURE – DEALLOCATION OVERVIEW 19 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
21. WINDOWS HEAP ALLOCATOR – LOGIC AND LAYOUT 21 argp & huku - FOSSCOMM 2011 Patras Heap Massacre Images from Practical Windows XP/2003 Heap Exploitation by J.McDonald and C.Valasek
22. WINDOWS HEAP ALLOCATOR – LOGIC AND LAYOUT 22 argp & huku - FOSSCOMM 2011 Patras Heap Massacre Chunk image from Practical Windows XP/2003 Heap Exploitation by J.McDonald and C.Valasek
23. USERSPACE ALLOCATOR SUMMARY  Freelists (bins) of small-medium sized areas  Thread Specific Data (TSD) / Thread Local Storage (TLS) for multithreaded applications  Possible caching (or alike e.g. unsorted_chunks() in Glibc)  Inline heap metadata  Built-in security mechanisms (assert(), page/chunk guards, magic cookies, safe unlink()’ing) 23 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
24. USERSPACE EXPLOITATION TECHNIQUES  Unlink exploitation (still possible?)  Bit flipping attacks on allocator’s bit vectors  Inline metadata overwriting (size, previous size, etc)  Global metadata overwriting (arena headers, chunk headers etc)  Other application specific attacks 24 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
25. KERNELSPACE ALLOCATORS  Linux  FreeBSD  Microsoft Windows Heap internals
26. EVERYBODY LOVES LINUX
27. KMALLOC() 27 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  SLAB, SLUB, SLOB, SLQB  All expose a common interface  kmalloc()/kzalloc(), kmem_cache_alloc()  Default: SLUB  SLAB’s enhanced and simplified descendant  Follows the traditional slab allocator design  Simplifications mainly for enhanced performance  $ cat /proc/slabinfo  SLUB: kmalloc-32, kmalloc-64, etc  SLAB: size-32, size-64, etc
28. SLUB OVERVIEW 28 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  Organizes physical memory frames in caches  Each cache holds slabs of objects of the same size  General caches: kmalloc-64, kmalloc-96, etc  Kernel structure specific caches: mm_struct, task_struct, dentry, etc  The objects on a slab are contiguous  A slab may have both allocated (used) and deallocated (free) objects
29. SLUB’S SLABS 29 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  Each slab is at least PAGE_SIZE bytes (default 4096)  A slab may span many pages  A kmalloc-32 slab has 128 objects (128 * 32 == 4096)  A task_struct (1088 bytes) slab has 30 objects (30 * 1088 == 32640)  A task_struct slab spans 8 pages (8 * 4096 == 32768)  Each CPU core has its own slabs
30. METADATA? 30 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  No separate/dedicated metadata structures stored on the slabs  Each free object stored on a slab has a next-free-object pointer  Each slab has a page structure (struct page) that has a pointer (freelist) to the first free object of the slab
31. SLUB BEHAVIOR 31 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  Partial slabs, some free, some used objects  New requests satisfied from partial slabs  Least-recently-used (LRU) policy  No partial slabs → new slab is allocated  Allocations on a new slab are consecutive and objects are contiguous  Generic slabs (e.g. kmalloc-32) are used to store objects of the same size  But the type can differ (i.e. different kernel structures)
32. SLUB MASSACRE  Corrupt the metadata of free objects on the slabs  Corrupt adjacent objects on the slabs  We need suitable kernel structures that we can allocate/deallocate at will from userland (e.g. syscall)  Selection depends on content  Selection also depends on size: we want it on the same slab as the object we can overflow from  Bring target slab to a predictable state in order to have the victim structure after the overflown structure 32 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
33. SLUB EXPLOITATION ALGORITHM 33 argp & huku - FOSSCOMM 2011 Patras Heap Massacre 1. Find free objects on target slab: /proc/slabinfo 2. Ensure allocations/deallocations happen on the slabs of the same CPU (sched_setaffinity(2)) 3. Consume a large number of objects that go on the target slab (reducing fragmentation) 4. Deallocate a small number of objects from the target slab 5. Allocate a smaller number of our selected victim objects 6. Trigger the overflow bug 7. Overwrite the structure/object we have selected  Exploitation is specific to the selected structure
34. SLUB EXPLOITATION ILLUSTRATED 34 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
35. VICTIM STRUCTURE 35 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  Traditionally struct shmid_kernel [KERNHEAP]  include/linux/shm.h  Allocations/deallocations controlled from userland  Allocation: shmget(2)  Deallocation: ipcrm(1)  Leads to structure with yummy function pointers
36. VICTRIM STRUCTURE – SHMID_KERNEL 36 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
37. VICTIM STRUCTURE – FILE 37 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
38. VICTIM STRUCTURE – FILE_OPERATIONS 38 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
40. UMA – UNIVERSAL MEMORY ALLOCATOR 40 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  FreeBSD’s kernel memory allocator  Funded by Nokia for a proprietary project  The IPSO firewall/security appliance (thanks FX!)  Donated to FreeBSD  Functions like a traditional slab allocator  Large areas, or slabs, of memory are initially allocated  Items of specific type and size are pre-allocated on the slabs  malloc(9) returns a pre-allocated item marked as free from a slab  Size adjusted for alignment to find a slab
41. UMA ARCHITECTURE – LOGIC AND LAYOUT 41 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
42. UMA ARCHITECTURE – ALLOCATION OVERVIEW 42 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
43. UMA ARCHITECTURE 43 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  Each zone (uma_zone) holds buckets (uma_bucket) of items  The items are allocated on the zone’s slabs (uma_slab)  Each zone is associated with a keg (uma_keg)  The keg holds the corresponding zone’s slabs  Each slab has a slab header (uma_slab_head) with metadata  Slab header may or may not be inline
44. UMA – SLABS 44 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
45. UMA – UMA_SLAB_HEAD STRUCTURE 45 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
46. UMA – UMA_KEG STRUCTURE 46 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
47. UMA – UMA_ZONE STRUCTURE 47 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
48. UMA – FUNCTION UMA_ZFREE_ARG() 48 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
49. UMA EXPLOITATION ALGORITHM 49 argp & huku - FOSSCOMM 2011 Patras Heap Massacre 1. Find free items on target zone 2. Consume all free items 3. Allocate enough items to fill a slab of the target zone  Trigger the overflow on all of these  One will be the last item on the slab 4. Overwrite the address of us_keg in uma_slab_head with a userland address 5. Construct a fake us_keg with the address of a fake uma_zone  Point the uz_dtor function pointer to the shellcode 6. Deallocate all items that triggered the overflow 7. free(9) → uma_zfree_arg() → uz_dtor() → shellcode
50. UMA EXPLOITATION FLOW 50 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
52. WINDOWS KERNEL POOL 52 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  The Windows kernel heap manager  Exposed to drivers and kernel internal components  Object = ExAllocatePool(Type, Bytes) → ExAllocatePoolWithTag(Type, Bytes, ‘enoN’)  ExFreePool(Object) → ExFreePoolWithTag(Object, 0)  Non-paged pool  Must always be in memory  Pages pool  Can be paged out  Managed by struct _POOL_DESCRIPTOR
53. WINDOWS KERNEL POOL – _POOL_DESCRIPTOR 53 argp & huku - FOSSCOMM 2011 Patras Heap Massacre Code excerpts from Windows Research Kernel v1.2 The WRK-v1.2 license allows it
54. WINDOWS KERNEL POOL – LISTHEADS 54 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
55. UNLINKING EXPLOITATION 55 argp & huku - FOSSCOMM 2011 Patras Heap Massacre
56. ABSTRACTING HEAP EXPLOITATION Heap internals
57. ABSTRACTING EXPLOITATION 57 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  Specific exploitation techniques will become obsolete  New software versions  Exploitation mitigations  Back in CS 101 we were told that the most important skill of a computer scientist is abstraction  The same holds for exploit writers/security researchers/hackers  Your ability to abstract will remain sharp (as long as you sharpen it)  Develop exploitation methodologies  Recognize/understand/reuse exploitation primitives
58. HEAP EXPLOITATION METHODOLOGY 58 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  Understand the heap manager with an exploitation mindset  Architecture (which are the important heap structures?)  Exposed API (what can I directly/indirectly control?)  Implementation (what happens when I allocate/deallocate?)  Memory layout (how do objects look in memory?)  Metadata (are there inline metadata?)  Identify exploitation primitives  Allocate/deallocate (predictable state)  Allocation granularity  Unlinking  Full, partial, free lists  Metadata overwriting (inline/local, global, bit vectors, size)  Use-after-free
59. REFERENCES 59 argp & huku - FOSSCOMM 2011 Patras Heap Massacre  [SLAB] Jeff Bonwick The Slab Allocator: An Object-caching Kernel Memory Allocator  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4759  [BLUE] Chris Valasek and Ryan Smith, Exploitation in the Modern Era (Blueprint)  https://www.blackhat.com/html/bh-eu-11/bh-eu-11- briefings.html#Valasek  [KERNHEAP] Larry Highsmith Linux Kernel Heap Tampering Detection  http://www.phrack.org/issues.html?issue=66&id=15&mode=txt
60. QUESTIONS 60 argp & huku - FOSSCOMM 2011 Patras Heap Massacre