Transcript DieHarder: Securing the Heap
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