1. Author: Gene Novark, Emery D. Berger University of Massachusetts Amherst DieHarder: Securing the Heap ACM CCS’10

2. 2

3. Outline 3 Introduction Memory Allocators Threat Model Heap Overflow Attacks Heap Spraying Attacks Dangling Pointer Attacks DieHarder Related Work Conclusion

4. Introduction 4 Exploitable memory management errors:  Heap overflows/underflows  Dangling pointers  Double free  Invalid free  Uninitialized reads

5. Introduction 5 Interaction between the memory management error and the heap layout  E.g. adjacent objects make overflow available In this paper…  Introduction and analysis  Like ASLR  Some modification on previous work

6. Memory Allocators 6 malloc(), free(), new(), delete() C library Implementation differs among OSes Primary goal: low fragmentation Windows, Linux, FreeBSD, OpenBSD  Freelist-based Allocators  BiBOP-style Allocators Ref: Memory Allocator Attack and DefenseMemory Allocator Attack and Defense

7. Freelist-based Allocators 7 Windows, Linux Doug Lea Allocator (DL-malloc) Doug Lea Allocator  1997-present  GNU libc’s allocator is based on DLmalloc 2.7 Inline metadata Contiguous External free list

8. Freelist-based Allocators 8 Each object has a header(metadata)  Status  Object size  Previous object size  Couple of pointers of doubly linked lists (freed objects only) LowHigh

9. Freelist-based Allocators 9 Free List (an array of doubly linked list)

10. Freelist-based Allocators 10 Pros : no additional memory to manage the linked list of free chunks Cons : vulnerable to heap-based attacks

11. BiBOP-style Allocators 11 FreeBSD, OpenBSD, (Apple OS X) “Big Bag of Pages” PHKmalloc (Poul-Henning Kamp malloc) PHKmalloc  FreeBSD (2.2 – 6.x)  FreeBSD (7.0 – present) : JEmalloc Page-resident metadata (?) Page directory Non-full page list

12. BiBOP-style Allocators 12 Page-aligned allocation (ref.)ref.  Page directory itself is stored in the heap (first allocated)  Each element in page directory represents a specific page (ptr)  Each page contains chunks of same size  Metadata is maintained in the page or in the heap  struct pginfo ; struct pgfree struct pginfo struct pgfree

13. BiBOP-style Allocators 13 OpenBSD (ref) OpenBSDref  Derived from PHKmalloc  Since ver. 4.4 1. Fully-segregated metadata 2. Sparse page layout  mmap() 3. Destroy-on-free (optional)  munmap(), overwrite freed objects 4. Randomized placement 5. Randomized reuse  Delayed reuse

14. Memory Allocators 14 Allocator Security Properties

15. Threat Model 15 Memory errors Application class  Object be allocated contiguously  Web browsers  Predictable heap  Large amount of allocation  Repeated attacks  Server application Threat model:  Repeated attacks  Allocate/free objects at will

16. Heap Overflow Attacks 16 Def: Source chunk, target chunk(s) Assume: an attack succeeds whenever a target chunk is overwritten Early attacks  Target chunk : function pointer (allocated object) Freelist metadata attacks (2000, Netscape-JPEG) (ref.)ref.  Target: 1. freelist pointers 2. a global function (ex: __free_hook )

17. An Example of a Freelist Metadata Attack 17 SS fd1bk1 #define unlink( P, BK, FD ) { [1] BK = P->bk; [2] FD = P->fd; [3] FD->bk = BK; [4] BK->fd = FD; } unused mem. fd0bk0fd2bk2 P Normal unlink BK [1] [2] FD BK FD [3] [4]

18. An Example of a Freelist Metadata Attack 18 SS fd1bk1 unused mem. fd0bk0fd2bk2 P BK [1] [2] FD [3] [4] overflow … XXSHFK SH X FK bk3 fd4 func 444 FK = &(*func) - 12 SH FD Unlink Attack #define unlink( P, BK, FD ) { [1] BK = P->bk; [2] FD = P->fd; [3] FD->bk = BK; [4] BK->fd = FD; }

19. Heap Overflow Attacks 19 Allocator analysis  Inline metadata  Vulnerable  Page-resident metadata  Lack of guard page  Guard pages  Against contiguous overrun  Not underrun or non-contiguous overflows (off-by-one)  Canaries  Overhead  Randomized placement  The entropy is low

20. Heap Spraying Attacks 20 Allocate hundreds of MB of shellcode Attack model:  No a priori knowledge  Known address attacks Allocator Analysis  No a priori knowledge  Guess the address of a target object  |V|  |H|, where V is the set of objects, H is the heap space  Known address attacks  If contiguously allocated, the target address related to a known address is guessable  If randomly allocated, the target address has minimal correlation with the known object.  Performance vs. predictability

21. Dangling Pointer Attacks 21 Use of a free chunk of memory  Write: “dangling pointer error”  Free: “double-free error” Reuse Vulnerabilities  A dangled object contains a function pointer  An attacker reuses the chunk for an attacker-controlled object (by forcing the allocator to use the chunk)  Call the function  ** reuse(write to) the dangled object immediately  OpenBSD:  16-element array  1/16 probability of reusing immediately  By Bernoulli trial, the distribution of this probability  approximately 5.4 bits of entropy

22. Dangling Pointer Attacks 22 Allocator analysis  t : the number of allocations before a just-freed object is recycled  Freelists  LIFO  t = 0 (?)  BiBOP-style allocators  PHKmalloc : t depends on the number of free chunks on a non-full page  Allocate same size objects  Coalescing  Unpredictable  Defragmented heap  lower chance to coalesce

23. A Dangling Pointer Attack Example 23 class Class_A { public: virtual long vfunc_A1(); virtual long vfunc_A2(); }; mov ecx, (object address); mov eax, [ecx]; call [eax+4]; VFtable ptr shellcode VFtable VFtable+4 eax object address call/jmp ecx+4; Fake object

24. DieHarder 24 A memory allocator designed with security as a primary goal Based on DieHard : strategy – highly unpredictableDieHard  Miniheaps, each contains same-size objects  M: multiplier of maximum needed size of the application  N: number of allocated objects  M = 2  M*N free heap chunks to choose  For each v belonging to V has a (MN –k)/MN chance of being outside the k object, where k is the number of object slots that follow v.  The probability of a successful attack  1 – ( (MN-k) / MN ) |V|

25. 25

26. DieHarder 26 Over-provision : O(N) free chunks  bit of entropy = O(log N) Randomized Placement Randomized Reuse

27. DieHarder 27 DieHarder  Sparse Page Layout  Like OpenBSD: mmap( )  Deallocation: use a hash table to store references to page metadata  constant time  Address Space Sizing  Restrict page randomization to smaller virtual address range To increase cache efficiency  Destroy-on-free  Fill freed objects with random data to reduce the integrity of attacker-controlled data

28. DieHarder 28 Pages are randomly distributed across a large address space  Pages protected by guard pages on both sides  H: number of allocated pages  S: size in page of allocated virtual address space  The chance of having a guard page after an allocated page  (S-H)/S  Consider a page of 16-byte chunks  256 chunks per page  The probability of 1-byte overflow crashing:  ((S-H) / S) * (1 / 256)

29. DieHarder 29 Evaluation – SPECint2006  Geometric mean: 20%  Perlbench, omnetpp, xalancbmk : high allocation rate

30. Related Work 30 Memory allocator security  Encrypted metadata  XOR-encoded  DLmalloc 2.8  Isolation of metadata  Different process Object-per-page allocators (special use)  One page for each objects  PageHeap, Electric Fence, Archipelago Safe C API, compiler solution(WIT)

31. Conclusion 31 This paper analyzes the impact of several memory allocator A new allocator, DieHarder, is proposed to enhance the heap security  Reduce overflow by isolating the metadata  Guard pages  Fully randomized placement  Destroyed on free  20% slower