Dangling Pointers Periklis Akritidis --2010 Use-after-free - - PowerPoint PPT Presentation

▶
dangling pointers
SMART_READER_LITE
LIVE PREVIEW

Dangling Pointers Periklis Akritidis --2010 Use-after-free - - PowerPoint PPT Presentation

Apr 30, 2023 219 likes •578 views

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

slide-1
SLIDE 1

Cling: A Memory Allocator to Mitigate Dangling Pointers

Periklis Akritidis --2010

slide-2
SLIDE 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

slide-3
SLIDE 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

slide-4
SLIDE 4

Dangling Pointer Attacks II

 C++ objects contain pointers to virtual tables (vtables)  Obstacle: freed object's pointer aligned with new

  • bject'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

slide-5
SLIDE 5

Naive Defence

 Avoiding Address Space Reuse  Has 3 Major Disadvantages:

 Address space exhaustion.  Limited reuseable physical memory. Memory

  • verhead of solving this is too high.

 High rate of system calls. Redusing this leads to

higher memory consumption.

5

slide-6
SLIDE 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

slide-7
SLIDE 7

Example of type-safe memory reuse

7

slide-8
SLIDE 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

slide-9
SLIDE 9

Cling Memory Allocator

  • Does not use free memory for metadata
  • Only allows type-safe address reuse
  • Achieves these without sacrificing performance

9

slide-10
SLIDE 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

slide-11
SLIDE 11

Out-of-Band Heap Metadata

  • Cling: Two-level allocation scheme
  • Non-intrusive linked lists chain

large memory chunks

  • Small allocations carved
  • ut of buckets using bitmaps

11

slide-12
SLIDE 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

slide-13
SLIDE 13

Pools

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

13

slide-14
SLIDE 14

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
  • bjects of a single type or arrays of objects of a single

type, which can safely share a pool

14

slide-15
SLIDE 15

One complication

  • Array elements not aligned if block size not multiple of
  • bject size
  • Solution: pool allocations according to size

15

slide-16
SLIDE 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

slide-17
SLIDE 17

Heap organization

17

slide-18
SLIDE 18

Cling Architecture

18

slide-19
SLIDE 19

Wrappers

  • A wrapper function ’s main purpose is to call a subroutine
  • r 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

slide-20
SLIDE 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

slide-21
SLIDE 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
  • ffset is found, unwind (using libunwind) is performed to confirm the

allocation site’s validity

21

slide-22
SLIDE 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
  • bjects

a function erroneously returns a pointer to a local variable

22

slide-23
SLIDE 23

Limitations ΙΙ

  • Cling relies on mapping allocation sites to object types.

When a program has contrived flow of control, that is

  • bscured.

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

slide-24
SLIDE 24

Implementation

  • Cling comes as a shared library providing

implementations for malloc and new

  • It can be preloaded with platform specific mechanisms to
  • verride 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

slide-25
SLIDE 25

Experimental Evaluation

  • Goal: CPU, physical memory & virtual address space
  • verheads of Cling vs GNU libc allocator
  • Two variations of Cling
  • Without wrapper unwinding
  • Using single pool

25

slide-26
SLIDE 26

Testbeds

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

26

slide-27
SLIDE 27

Execution time

27

slide-28
SLIDE 28

One vs. many pools

28

slide-29
SLIDE 29

Memory

29

slide-30
SLIDE 30

One vs. many pools

30

slide-31
SLIDE 31

Address space

31

slide-32
SLIDE 32

Effects of unwinding

32

slide-33
SLIDE 33

Firefox memory

33

slide-34
SLIDE 34

Firefox VM

34

slide-35
SLIDE 35

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