code-pointer integrity - code-pointer separation identify code-pointer accesses using static...

Code-Pointer Integrity

Volodmyr Kuzentsov, László Szekeres, Mathias Payer, George Candea, R. Sekar, and Dawn Song

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

Memory Corruption is Abundant!

2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 0

30

60

90

120

150 Acrobat Firefox IE OS X Linux Average

Co nt

ro l-F

lo w

H ija

ck C

VE s

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

Memory safety: invalid dereference

Dangling pointer: (temporal)

Out-of-bounds pointer: (spatial)

● Violation iff – Pointer is read – Pointer is written – Pointer is freed

● No violation – Otherwise

Threat Model

● Attacker can read/write data, read code ● Attacker cannot

– Modify program code – Influence program loading

Code Heap Stack

RW RWRX

Control-Flow Hijack Attack

void *(func_ptr)(); int *q = buf + input; … func_ptr = &foo; … *q = input2; … (*func_ptr)();

Memory

buf

func_ptr

gadget

1

1

2

2

3

func_ptr

qq

Data Execution Prevention ('06)

Image: http://www.computing.co.uk

Address Space Layout Randomization ('05)

Image: Ted Atchley, http://torwars.com Canaries ('06)

Image: http://socialcanary.com

What about existing defenses?

Presented at 30c3

http://youtu.be/CQbXevkR4us

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

Memory Safety to the Rescue

Swift

MEMORY SAFETY FIRST

Python code ~3 kloc

Python runtime ~500 kloc

libc ~2,500 kloc

Linux kernel ~15,803 klocUns afe

!

SAFE LANGUAGES

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

Retrofit Memory Safety

SoftBound+CETS 116% MEMORY SAFETY FIRSTCCured 56%

AddressSanitizer 73%

C/C++ Overhead

Memory Safety

char *buf = malloc(10);

… char *q = buf + input;

*q = input2; … (*func_ptr)();

buf_lo = p; buf_up = p+10;

q_lo = buf_lo; q_up = buf_up; if (q < q_lo || q >= q_up) abort();

1. Assign meta-data

2. Propagate meta-data

3. Check meta-data

116% performance overhead (Nagarakatte et al., PLDI'09 and ISMM'10)

Safety vs.

Flexibility and Performance

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

Presented at 30c3

http://youtu.be/2ybcByjNlq8

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

New Approach: Protect Select Data

Code Heap Stack Safe Stack

Strong protection for a select subset of data Attacker may modify any unprotected data

Instead of protecting everything a little

protect a little completely

Memory Safety (116% performance overhead)

Control-Flow Hijack Protection (1.9% or 8.4% performance overhead)

? Protect onlyCode Pointers

Code-Pointer Separation: Heap

Separate Program memory

Memory

buf

func_ptr

q

Regular Memory

buf

func_ptr

q

Safe Memory

func_ptrfunc_ptr

Code Pointers

only

All other data

Memory Layout

unchanged

Control plane: either code

pointer or NULL

Code-Pointer Separation: Stack

Safe Stack

ret address

Regular Stack

buf

int foo() {

char buf[16];

int r;

r = scanf(“%s”, buf);

return r;

}

r

Safely Accessed

locals

Locals accessed through pointers

Any location may be

corrupted

CPS Memory Layout

Safe Memory Regular Memory (code pointers) (non-code-pointer data)

Accesses are safe Accesses are fast

Hardware-based instruction-level isolation

Regular HeapSafe Heap

Safe Stack (Thread 1)

Safe Stack (Thread 2)

Regular Stack (Thread 1)

Regular Stack (Thread 2)

... ...

Code (Read-Only)

Attacking Code-Pointer Separation

void *(func_ptr)();

… func_ptr = struct_ptr->f; … (*func_ptr)();

Memory

struct_ptr

func_ptr'

func_ptr

struct_ptr'

int *q = buf + input; *q = input2; int *q = buf + input; *q = input2;

NULL or a ptr to another

function

Code-Pointer Separation

● Identify Code-Pointer accesses using static type-based analysis ● Separate using instruction-level isolation (e.g., segmentation)

● CPS security guarantees – An attacker cannot forge new code pointers – Code-Pointer is either immediate or assigned from code pointer – An attacker can only replace existing functions through indirection:

e.g., foo->bar->func() vs. foo->baz->func2()

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

Code-Pointer Integrity (CPI)

Sensitive Pointers = code pointers and pointers used to access sensitive pointers

● CPI identifies all sensitive pointers using an over-approximate type-based static analysis:

is_sensitive(v) = is_sensitive_type(type of v)

● Over-approximation only affects performance On SPEC2006

Attacking Code-Pointer Integrity

void *(func_ptr)();

func_ptr = struct_ptr->f; … (*func_ptr)();

int *q = buf + input;

*q = input2;

Exception when

dereferenced

q_lo = buf_lo; q_up = buf_up; if (q < q_lo || q >= q_up) abort();

Code-Pointer Integrity vs. Separation

● Separate sensitive pointers from regular data – Type-based static analysis – Sensitive pointers = code pointers + pointers to sensitive pointers

● Accessing sensitive pointers is safe – Separation + runtime (bounds) checks

● Accessing regular data is fast – Instruction-level safe region isolation

Security Guarantees

● Code-Pointer Integrity: formally guaranteed protection – 8.4% to 10.5% overhead (~6.5% of memory accesses)

● Code-Pointer Separation: strong protection in practice – 0.5% to 1.9% overhead (~2.5% of memory accesses)

● Safe Stack: full ROP protection – Negligible overhead

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

Implementation

● LLVM-based prototype – Front end (clang): collect type information – Back-end (llvm): CPI/CPS/SafeStack instrumentation pass – Runtime support: safe heap and stack management – Supported ISA's: x64 and x86 (partial) – Supported systems: Mac OSX, FreeBSD, Linux

Current status

● Great support for CPI on Mac OSX and FreeBSD on x64 ● Upstreaming in progress

– Safe Stack coming to LLVM soon – Fork it on GitHub now: https://github.com/cpi-llvm

● Code-review of CPS/CPI in process – Play with the prototype: http://levee.epfl.ch/levee-early-preview-0.2.tgz – Will release more packages soon

● Some changes to super complex build systems needed – Adapt Makefiles for FreeBSD

https://github.com/cpi-llvm http://levee.epfl.ch/levee-early-preview-0.2.tgz

Is It Practical?

● Recompiled entire FreeBSD userpsace ● … and more than 100 packages

PostgreSQL OpenSSL

hardened

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

Conclusion

● CPI/CPS offers strong control-flow hijack protection – Key insight: memory safety for code pointers only

● Working prototype – Supports unmodified C/C++, low overhead in practice – Upstreaming patches in progress, SafeStack available soon! – Homepage: http://levee.epfl.ch – GitHub: https://github.com/cpi-llvm

http://levee.epfl.ch/ https://github.com/cpi-llvm

(c) TriStar Pictures, Inc. & Touchstone Pictures, 1997

http://levee.epfl.ch http://nebelwelt.net/publications/14OSDI/

?

Slide 1 Slide 2 Slide 3 Slide 4 Slide 5 Slide 6 Slide 7 Current protection Slide 9 Slide 10 Slide 11 Slide 12 Slide 13 Slide 14 Slide 15 Slide 16 Slide 17 Slide 18 Slide 19 Slide 20 Slide 21 Slide 22 Slide 23 Slide 24 Slide 25 Slide 26 Slide 27 Slide 28 Slide 29 Slide 30 Slide 31 Slide 32 Slide 33 Slide 34