Cling: A Memory Allocator to Mitigate Dangling Pointers. Periklis Akritidis

Transcription

1 Cling: A Memory Allocator to Mitigate Dangling Pointers Periklis Akritidis

2 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

3 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

4 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

5 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

6 Type-Safe Memory Reuse Allows dangling pointers only to objects of same type and alignment Shared vtable pointers are at the same offsets 6

7 7 Example of type-safe memory reuse

8 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

9 Cling Memory Allocator Does not use free memory for metadata Only allows type-safe address reuse Achieves these without sacrificing performance 9

10 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

11 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

12 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

13 Pools Group of memory addresses dedicated for the allocation of a single type 13

14 Type-Safe Address Space Reuse Observations towards solution: security maintained even if memory reuse is overconstrained 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

15 One complication Array elements not aligned if block size not multiple of object size Solution: pool allocations according to size 15

16 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

17 Heap organization 17

18 Cling Architecture 18

19 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 size, lptr); return lptr; } 19

20 Clings challenges: 1. Discover wrappers 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

21 Clings challenges: 2. Unwinding malloc wrappers 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

22 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

23 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

24 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

25 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

26 Testbeds SPEC CPU 2000 & 2006 Results with at least 100K allocations espresso Mozilla Firefox Browsers prime target of use-after-free attacks) 26

27 Execution time 27

28 One vs. many pools 28

29 Memory 29

30 One vs. many pools 30

31 Address space 31

32 Effects of unwinding 32

33 Firefox memory 33

34 Firefox VM 34

35 References Wikipedia Stack overflow Paper Cling: A Memory Allocator to Mitigate Dangling Pointers, Periklis Akritidis Rest s03/src/interposition/mymalloc.c 35