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

PBK [1]

[2]FD

[3]

[4]

overflow

…

X X SHFK

SH

X

FK

bk3

fd4

func

44 4FK = &(*func) - 12 SH

FDUnlink 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

VFtableVFtable+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, ArchipelagoSafe 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