DieHarder: Securing the Heap

A u t h o r : G e n e N o v a r k , E m e r y D. B e r g e r U n i v e r s i t y o f M a s s a c h u s e t t s A m h e r s t

ACM CCS’10

2

Outline

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

Introduction

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

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

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 Defense

Freelist-based Allocators

7      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

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) Low High

Freelist-based Allocators

9  Free List (an array of doubly linked list)

Freelist-based Allocators

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

BiBOP-style Allocators

11       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

BiBOP-style Allocators

12  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 struct pginfo ; struct pgfree

BiBOP-style Allocators

13  OpenBSD  ( ref ) Derived from PHKmalloc  Since ver. 4.4

1.

2.

 Fully-segregated metadata Sparse page layout mmap() 3.

 Destroy-on-free (optional) munmap() , overwrite freed objects 4.

Randomized placement 5.

 Randomized reuse Delayed reuse

Memory Allocators

14 Allocator Security Properties

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

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.

)  Target: 1. freelist pointers 2. a global function (ex: __free_hook )

BK [1]

An Example of a Freelist Metadata Attack

17 #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 S S fd1 bk1 unused mem.

fd2 bk2 BK [4] Normal unlink

SH

An Example of a Freelist Metadata Attack

18 fd4 FD [4] … Unlink Attack #define unlink( P, BK, FD ) { [1] BK = P->bk; [2] FD = P->fd; [3] FD->bk = BK; [4] BK->fd = FD; } BK [1] P fd0 bk0 overflow unused mem.

fd2 bk2 FK = &(*func) - 12 FK [2] FD func 4 4 4 bk3 SH [3]

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

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

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

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

A Dangling Pointer Attack Example

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

DieHarder

24    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|

25

DieHarder

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

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

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)

DieHarder

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

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)

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