Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Patras Heap Massacre

argp
May 08, 2011

Patras Heap Massacre

FOSSCOMM 2011 (with Chariton Karamitas)

argp

May 08, 2011
Tweet

More Decks by argp

Other Decks in Research

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
  12. None
  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
  16. None
  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
  20. None
  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
  39. None
  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
  51. None
  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