Cling: A Memory Allocator to Mitigate Dangling Pointers Periklis Akritidis --2010
Use-after-free Vulnerabilities Accessing Memory Through Dangling Pointers Techniques : Heap Spraying, Feng Shui Manual memory management is error prone Existing techniques have several disadvantages 2
Dangling Pointer Attacks Use-after-free errors are temporal memory safety violations Access the contents of some other object that happens to occupy the memory at the time Placing a buffer with attacker data is complicated Solution is the use of Heap Spraying. 3
Dangling Pointer Attacks II C++ objects contain pointers to virtual tables (vtables) Obstacle: freed object's pointer aligned with new object's pointer Solution: Use of multiple inheritance objects Attacks not limited to control flow Hijacking Data Fields Writing to an arbitrary memory location Information Leaks 4
Naive Defence Avoiding Address Space Reuse Has 3 Major Disadvantages: Address space exhaustion. Limited reuseable physical memory. Memory overhead of solving this is too high. High rate of system calls. Redusing this leads to higher memory consumption. 5
Type-Safe Memory Reuse • Allows dangling pointers only to objects of same type and alignment • Shared vtable pointers are at the same offsets 6
Example of type-safe memory reuse 7
Type-safe memory reuse still enables attacks • Data structures holding credentials or access control information • Buffer size stored separately from data can be detected through spatial protection mechanisms 8
Cling Memory Allocator • Does not use free memory for metadata • Only allows type-safe address reuse • Achieves these without sacrificing performance 9
Heap Metadata In-band attack: • Heap based overflows can corrupt allocator metadata Defense: • Sanity checks on free list pointers • Using heap canaries Cannot prevent use-after-free vulnerabilities 10
Out-of-Band Heap Metadata • Cling: Two-level allocation scheme • Non-intrusive linked lists chain large memory chunks • Small allocations carved out of buckets using bitmaps 11
Type-Safe Address Space Reuse Two challenges need to be addressed: • Semantic gap between runtime and compile time availability of type info • Memory overhead caused by pools 12
Pools Group of memory addresses dedicated for the allocation of a single type 13
Type-Safe Address Space Reuse Observations towards solution: • security maintained even if memory reuse is over- constrained • in C/C++ programs, an allocation site typically allocates objects of a single type or arrays of objects of a single type, which can safely share a pool 14
One complication • Array elements not aligned if block size not multiple of object size • Solution: pool allocations according to size 15
Type-Safe Address Space Reuse What about overhead? • physical memory, unlike address space, can be safely reused across pools • Cling returns individual blocks of memory to the operating system once completely free • Deallocated memory accessed through a dangling pointer will either continue to hold the data of the intended object, or will be zero-filled by the OS 16
Heap organization 17
Cling Architecture 18
Wrappers • A wrapper function ’s main purpose is to call a subroutine or a system call (like malloc) with little or no additional computation. • Wrappers obscure real allocation site • Cling cannot associate it with a distinct pool /* This function wraps the real malloc */ void * __wrap_malloc (size_t size) { void *lptr = __real_malloc(size); printf("Malloc: %lu bytes @%p\n", size, lptr); return lptr; } 19
Clings’ challenges: Discover wrappers 1. • Cling initiates a probing mechanism after observing a single allocation site requesting multiple allocation sizes • interpose on return of potential wrapper • check if returned value matches most recent allocation • allocation sites identified as potential wrappers are marked 20
Clings’ challenges: Unwinding malloc wrappers 2. • Cling unwinds one more stack level • Stores the stack offset of wrappers’ return addresses • When a new allocation site is that was retrieved using a stored stack offset is found, unwind (using libunwind) is performed to confirm the allocation site’s validity 21
Limitations • Cannot prevent use-after-free attacks targeting data such as credentials a dangling pointer that used to point to the credentials of one user may end up pointing to the credentials of another user • Cling cannot prevent unsafe reuse of stack allocated objects a function erroneously returns a pointer to a local variable 22
Limitations ΙΙ • Cling relies on mapping allocation sites to object types. When a program has contrived flow of control, that is obscured. int size = condition ? sizeof( struct A) : sizeof(struct B); void *obj = malloc(size); • Usability in 32-bit platforms with scarce address space is limited 23
Implementation • Cling comes as a shared library providing implementations for malloc and new • It can be preloaded with platform specific mechanisms to override the system’s memory allocation routines at program load time If you set LD_PRELOAD to the path of a shared object, that file will be loaded before any other library (including the C runtime, libc.so). $ LD_PRELOAD=/path/to/my/malloc.so/bin/ls) 24
Experimental Evaluation • Goal: CPU, physical memory & virtual address space overheads of Cling vs GNU libc allocator • Two variations of Cling • Without wrapper unwinding • Using single pool 25
Testbeds • SPEC CPU 2000 & 2006 • Results with at least 100K allocations • espresso • Mozilla Firefox • Browsers prime target of use-after-free attacks) 26
Execution time 27
One vs. many pools 28
Memory 29
One vs. many pools 30
Address space 31
Effects of unwinding 32
Firefox memory 33
Firefox VM 34
References • Wikipedia http://en.wikipedia.org/wiki/Wrapper_function • • Stack overflow http://stackoverflow.com/questions/426230/what-is-the-ld-preload- • trick • Paper Cling: A Memory Allocator to Mitigate Dangling Pointers , Periklis • Akritidis • Rest http://www.cs.cmu.edu/afs/cs/academic/class/15213- • s03/src/interposition/mymalloc.c http://savannah.nongnu.org/projects/libunwind/ • 35
Recommend
More recommend