Download - Automatically Tolerating And Correcting Memory Errors

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTS ASSACHUSETTS AAMHERST • MHERST • Department of Computer Science Department of Computer Science • 2007 • 2007

Automatically Tolerating &Correcting Memory Errors

Emery BergerUniversity of Massachusetts Amherst

joint work with Gene Novark (UMass Amherst),Ben Zorn (Microsoft Research)

[PLDI 2006, PLDI 2007]


Problems with Unsafe Languages

C, C++: pervasive apps, but langs.memory unsafe

Numerous opportunities for security vulnerabilities, errors Double free Invalid free Uninitialized reads Dangling pointers Buffer overflows (stack & heap)


Current Approaches

Unsound, may work or abort Windows, GNU libc, etc., Rx [Zhou]

Unsound, will definitely continue Failure oblivious [Rinard]

Sound, definitely aborts (fail-safe) CCured [Necula], CRED [Ruwase & Lam], SAFECode

[Dhurjati, Kowshik & Adve], etc. Slowdowns: 30% - 20X Requires C source, programmer intervention Garbage collection or partially sound (pools)

Good for debugging, less for deployment


Soundness for “Erroneous” Programs

Normally: memory errors ? Consider infinite-heap allocator:

All news fresh;ignore delete

No dangling pointers, invalid frees,double frees

Every object infinitely large No buffer overflows, data overwrites

Transparent to correct program “Erroneous” programs sound


Probabilistic Memory Safety

Approximate with M-heaps (e.g., M=2)

DieHard: fully-randomized M-heap Increases odds of benign errors Probabilistic memory safety

i.e., P(no error) n Errors independent across heaps

E(users with no error) n * |users|

? Efficient implementation…


Implementation Choices

Conventional, freelist-based heaps Hard to randomize, protect from errors

Double frees, heap corruption What about bitmaps? [Wilson90]

– Catastrophic fragmentation Each small object likely to occupy one page

obj obj objobj

pages


Randomized Heap Layout

Bitmap-based, segregated size classes Bit represents one object of given size

i.e., one bit = 2i+3 bytes, etc. Prevents fragmentation

00000001 1010 10

size = 2i+3 2i+

4

2i+

5

metadata

heap


Randomized Allocation

malloc(8): compute size class = ceil(log2 sz) – 3 randomly probe bitmap for zero-bit (free)

Fast: runtime O(1) M=2 E[# of probes] ≈ 2

00000001 1010 10

size = 2i+3 2i+

4

2i+

5

metadata

heap


malloc(8): compute size class = ceil(log2 sz) – 3 randomly probe bitmap for zero-bit (free)

Fast: runtime O(1) M=2 E[# of probes] ≈ 2

00010001 1010 10

size = 2i+3 2i+

4

2i+

5

metadata

heap

Randomized Allocation


free(ptr): Ensure object valid – aligned to right address Ensure allocated – bit set Resets bit

Prevents invalid frees, double frees

00010001 1010 10

size = 2i+3 2i+

4

2i+

5

metadata

heap

Randomized Deallocation





00010001 1010 10

size = 2i+3 2i+

4

2i+

5

metadata

heap




00000001 1010 10

size = 2i+3 2i+

4

2i+

5

metadata

heap



Randomized Heaps & Reliability

2 34 5 3 1 6

object size = 2i+4

object size = 2i+3

…

11 6 3 2 5 4 …

My Mozilla: “malignant” overflow

Your Mozilla: “benign” overflow

Objects randomly spread across heap Different run = different heap

Improves security Errors across heaps independent


DieHard software architecture

broadcast vote

input output

execute replicas(separate processes)

replica3seed3

replica1seed1

replica2seed2

Optional: replication-based fault-tolerance Requires randomization: errors independent


DieHard Results

Analytical results (pictures!) Dangling pointer errors Buffer overflows Uninitialized reads

Empirical results Runtime overhead Error avoidance

Injected faults & actual applications


Analytical Results: Dangling Pointers

Free one object too early




Object extremely unlikely to be reused soon




Object extremely unlikely to be reused soon

Example: F = 1,000,000 P(ok after one malloc) ¼ 1 P(ok after 1000 mallocs) ¸ 99.9%

F = # free objectsA = # mallocs


Analytical Results: Buffer Overflows

Model overflow: random write of live data Heap half full (max occupancy)



Replicas: Increase odds of avoiding overflow in at least one replica

repl

icas



Replicas: Increase odds of avoiding overflow in at least one replica

repl

icas

P(Overflow in all replicas) = (½)3 = 1/8 P(No overflow in ≥ 1 replica) = 1-(½)3 = 7/8



F = free spaceH = heap sizeN = # objects

worth of overflow

k = replicas

Overflow one object


Empirical Results: Error Avoidance

Injected faults: Dangling pointers (@50%, 10 allocations)

glibc: crashes; DieHard: 9/10 correct Overflows (@1%, 4 bytes over) –

glibc: crashes 9/10, “inf loop”; DieHard: 10/10 correct Real faults:

Avoids Squid web cache overflow Crashes BDW & glibc

Avoids dangling pointer error in Mozilla DoS in glibc & Windows


DieHard Limitations

Fine for single error But: multiple errors eventually swamp

probabilistic protection Not great for large overflows

Tolerates errors But doesn’t find them

No information for programmer Ideal: point directly to bug…


Exterminator:Automatically Correcting

Memory Errors with High Probability


Diagnosing Buffer Overflows

Canonical buffer overflow: Allocate object – too small Write past end ) nukes object bytes forward

Not necessarily contiguous

char * str = new char[8];strcpy (str, “goodbye cruel world”);





bad object(too small)






bad object(too small)

bytes past end






bytes past end






bytes past end


1. Heap provides no useful information





bytes past end


2. No way to detect corruption


Isolating Buffer Overflows

8 2 9 3 4 5 1 7

Red =possiblebadobject

Green =notbadobject

Canaries in freed space detect corruption

known random value dead canary = corruption

# = object id (allocation time)



8 2 9 3 4 5 1 7


Green =notbadobject

Canaries in freed space detect corruption Run multiple times with “DieFast” allocator


Canaries in freed space detect corruption Run multiple times with “DieFast” allocator

8 2 9 3 4 5 1 7



Green =notbadobject

1 8 7 5 3 2 9 6 4


Canaries in freed space detect corruption Run multiple times with “DieFast” allocator Key insight: Overflow must be at same

8 2 9 3 4 5 1 7



Green =notbadobject

1 8 7 5 3 2 9 6 4


8 2 9 4 5 1 7



Green =notbadobject

1 8 7 5 3 2 9 6 4

3



8 2 9 3 4 5 1 7



Green =notbadobject

1 8 7 5 3 2 9 6 4



8 2 9 3 4 5 1 7



Green =notbadobject

1 8 7 5 3 6 492




8 2 9 3 4 5 1 7


Green =notbadobject

1 8 7 5 3 2 9 6 4

4 9 6 38 5 72 1


) object 9 overflowed, with high probability


Buffer Overflow Analysis

Example: H = 1,000,000 objects3 iterations ¼ false positives

Iterations exponentially increase precision

H = # heap objectsK = # iterations

11;000;000

8 2 9 3 4 5 1 7

1 8 7 5 3 2 9 6 4

4 9 6 38 5 72 1


Isolating Dangling Pointers

Dangling pointer error: Allocated object freed too soon Overwritten by some other object

int * v = new int[4];…delete [] v; // oops…char * str = new char[16];strcpy (str, “die, pointer”);v[3] = 12;… use of v[0]


Isolating Dangling Pointers

Unlike buffer overflow: dangling pointer ) same corruption in all

k = 3 ) false negatives ¼P(identical over°ow) ·

µS

H ¡ 1

¶k¡ 1

11;000;000

2

11 2 3 6 4 5 10 1 12 798

1 7 5 3 2 1112 648 9 10

4 6 312 5 72 1410 8 9


Correcting Allocator

Generate runtime patches to correct errors Track object call sites in allocator

Prevent overflows: pad overflowed objects

malloc(8) malloc(8 + δ)

Prevent dangling pointers: defer freesfree(ptr) delay δ mallocs;

free(ptr)

1 1


Exterminator Summary

Three main pieces: DieHard-based allocator (DieFast)

Reveals bugs Error isolator

Finds bugs across multiple heaps w.h.p. Correcting allocator

Fixes bugs Modes suitable for testing (debugging)

or deployment


Exterminator Modes

Iterative Run multiple times Same inputs Debugging

Replicated Run simultaneously Deployable w/limitations Can fix errors on-the-fly

Cumulative Different inputs, nondeterminism Deployable; see paper for details

seed

votebroadcast

input output

DieFast replica1seed

DieFast replica2seed

Error isolator

correcting allocator



DieFast replica3

runtime patches


Exterminator Runtime Overhead

25%


Empirical Results: Real Faults

Squid heap overflow Crashes glibc 2.8.0 and BDW collector 3 iterations to fix ) 6 byte pad

Prevents overflow for all subsequent executions


Mozilla 1.7.3 buffer overflow Debug scenario:

repeated load of PoC: 23 runs to fix overflow

Deployed scenario: different browsing sessions: 34 runs to fix

2

Empirical Results: Real Faults

31

1

2


Conclusion Randomization: enables

probabilistic memory safety (DieHard)& automatic error correction (Exterminator)

Trades hardware resources(RAM,CPU) for reliability Hardware trends

Larger memories, multi-core CPUs Follows in footsteps of

ECC memory, RAID


The End

www.diehard-software.orgwww.cs.umass.edu/~emery


4 3 6 5218

16

allocation space

bitmap

1

object size

2inUse

4inUse

1inUse

6inUse

1inUse

miniheaps

Actual DieHard Heap Layout

Bitmap-based, segregated size classes Bit represents one object of given size

i.e., one bit = 2i+3 bytes, etc.

malloc(): randomly probe bitmap for free space free(): just reset bit