DieHarder: Securing the Heap
Author : Gene Novark ,
E m e r y D. B e r g e r
University of Massachusetts Amherst
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
Fully-segregated metadata
2. Sparse page layout
1.

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)
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.
[4]
BK
[1]
Normal unlink
fd2 bk2
BK
SH
An Example of a Freelist Metadata Attack
18
fd4
FD
…
[4]
BK
[1]
fd0 bk0
#define unlink( P, BK, FD ) {
[1] BK = P->bk;
[2] FD = P->fd;
[3] FD->bk = BK;
[4] BK->fd = FD;
}
Unlink Attack
P
overflow
S
X
S fd1
X
FK bk1
SH unused
X
mem.
fd2 bk2
[2]
FD
func
FK = &(*func) - 12
FK
4
4
4 bk3
SH
[3]
Heap Overflow Attacks
19
 Allocator analysis
 Inline metadata


Page-resident metadata


Vulnerable
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
VFtable ptr
Fake object
VFtable
VFtable+4
shellcode
mov ecx, (object address);
mov eax, [ecx];
call [eax+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


