Upload
baldwin-flowers
View
214
Download
0
Embed Size (px)
Citation preview
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
DieHarder: Securing the Heap
ACM CCS’10
2
3
Outline
IntroductionMemory AllocatorsThreat ModelHeap Overflow AttacksHeap Spraying AttacksDangling Pointer AttacksDieHarderRelated WorkConclusion
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 libraryImplementation differs among OSesPrimary goal: low fragmentation
Windows, Linux, FreeBSD, OpenBSD Freelist-based Allocators BiBOP-style Allocators
Ref: Memory Allocator Attack and Defense
7
Freelist-based Allocators
Windows, LinuxDoug Lea Allocator (DL-malloc)
1997-present GNU libc’s allocator is based on DLmalloc 2.7
Inline metadataContiguousExternal 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 directoryNon-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 struct pginfo ; struct pgfree
13
BiBOP-style Allocators
OpenBSD (ref) Derived from PHKmalloc Since ver. 4.4
1. Fully-segregated metadata2. Sparse page layout
mmap()
3. Destroy-on-free (optional) munmap(), overwrite freed objects
4. Randomized placement5. Randomized reuse
Delayed reuse
14
Memory Allocators
Allocator Security Properties
15
Threat Model
Memory errorsApplication 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
S S fd1 bk1
#define unlink( P, BK, FD ) { [1] BK = P->bk; [2] FD = P->fd; [3] FD->bk = BK; [4] BK->fd = FD; }
unusedmem.
fd0 bk0 fd2 bk2
P
Normal unlinkBK [1]
[2]FD
BK
FD
[3]
[4]
18
An Example of a Freelist Metadata Attack
S S fd1 bk1 unusedmem.
fd0 bk0 fd2 bk2
P
BK [1]
[2]FD
[3]
[4]
overflow
…
X X SHFK
SH
X
FK
bk3
fd4
func
44 4FK = &(*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
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 shellcodeAttack 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 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
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();
};
mov ecx, (object address);mov eax, [ecx];call [eax+4];
VFtable ptr
shellcode
VFtable
VFtable+4
eaxobjectaddress
call/jmp ecx+4;
Fake object
24
DieHarder
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
26
DieHarder
Over-provision : O(N) free chunks bit of entropy = O(log N)
Randomized PlacementRandomized 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