DieHarder : Securing the Heap

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

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

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

5. Introduction • 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 • 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 Defense

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

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

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

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

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

12. BiBOP-style Allocators • Page-aligned allocation (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 • structpginfo; structpgfree

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

14. Memory Allocators Allocator Security Properties

15. Threat Model • 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 • 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.) • Target: 1. freelist pointers 2. a global function (ex: __free_hook)

17. An Example of a Freelist Metadata Attack #define unlink( P, BK, FD ) { [1] BK = P->bk; [2] FD = P->fd; [3] FD->bk = BK; [4] BK->fd = FD; } [2] FD [3] P FD fd0 bk0 fd1 bk1 unused mem. fd2 bk2 S S BK [4] BK [1] Normal unlink

18. An Example of a Freelist Metadata Attack SH #define unlink( P, BK, FD ) { [1] BK = P->bk; [2] FD = P->fd; [3] FD->bk = BK; [4] BK->fd = FD; } fd4 … FD [4] Unlink Attack BK [1] P fd0 bk0 fd1 bk1 unused mem. fd2 bk2 overflow S X S X FK SH X [2] FD func 4 4 4 bk3 FK = &(*func) - 12 SH [3] FK

19. Heap Overflow Attacks • 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 • 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 • Use of a free chunk of memory • Write: “dangling pointer error” • Free: “double-free error” • Reuse Vulnerabilities • A dangled object contains a function pointer • Anattacker 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 • 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 class Class_A { public: virtual long vfunc_A1(); virtual long vfunc_A2(); }; movecx, (object address); moveax, [ecx]; call [eax+4]; object address eax Fake object VFtableptr VFtable VFtable+4 call/jmp ecx+4; shellcode

24. DieHarder • A memory allocator designed with security as a primary goal • Based on DieHard : strategy – highly unpredictable • DieHard • 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|

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

27. DieHarder • 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 • 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 • Evaluation – SPECint2006 • Geometric mean: 20% • Perlbench, omnetpp, xalancbmk : high allocation rate

30. Related Work • 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 • 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