CSE 227 Computer Security Spring 2010 S f o t ftware D f e enses I Ste St f e an f Sa v Sa a v g a e g

Size: px

Start display at page:

Download "CSE 227 Computer Security Spring 2010 S f o t ftware D f e enses I Ste St f e an f Sa v Sa a v g a e g"

Allen Fleming
5 years ago
Views:

1 CSE 227 Computer Security Spring 2010 Software Df Defenses I Stefan Savage

2 Kinds of defenses Eliminate violation of runtime model Better languages, code analysis Don t allow bad input Input validation Detect overflow/overwrite of data structures Stack validation Run time bounds checking, pointer validation, etc Reference monitors Anomaly detection Don t allow untrusted code to execute Hardware protection, code signing Minimizeinvariants invariants for making repeatable exploits ASLR, code randomization, encrypted pointers Detect payload insertion before it can be invoked Minimize impact of untrusted code running (sandboxing) April 20,

3 Nozzle Goal: detect heap spraying attacks Slides ld courtesy Ratanaworabhan, Livshits, and Zorn

4 Drive By Heap Spraying Owned! 4

5 Drive By Heap Spraying (2) ASLR prevents the Program Heap attack ok ok bad PC Creates the malicious object <HTML> <SCRIPT language="text/javascript"> shellcode = unescape("%u4343%u4343%...''); Triggers the jump </SCRIPT> <IFRAME SRC=file://BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB NAME="CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC "> </IFRAME> </HTML> 5

6 Drive By Heap Spraying (3) Program Heap ok bd bad ok bad bad bad bad bd bad <SCRIPT language="text/javascript"> shellcode = unescape("%u4343%u4343%...''); oneblock = unescape("%u0c0c%u0c0c"); var fullblock = oneblock; Allocate 1000s of while (fullblock.length<0x40000) { malicious objects fullblock += fullblock; spraycontainer = new Array(); for (i=0; i<1000; i++) { spraycontainer[i] = fullblock + shellcode; </SCRIPT> 6

7 Local Malicious Object Detection Is this object dangerous? Codeor or Data? add [eax], al add [eax], al add [eax], al add [eax], al add [eax], al add [eax], al add [eax], al NOP sled and ah, [edx] and ah, [edx] and ah, [edx] and ah, [edx] and ah, [edx] and ah, [edx] and ah, [edx] shellcode Is this object code? Code and data look the same on x86 Focus on sled detection Majority of object is sled Spraying scripts build simple sleds Is this code a NOP sled? Previous techniques do not look at heap Many heap objects look like NOP sleds 80% false positive rates using previous techniques Need stronger local techniques 7

8 Object Surface Area Calculation (1) Assume: attacker wants to reach shell code from jump to any point in object Goal: find blocks that arelikely to be reached via control flow Strategy: use dataflow analysis to compute surface area of each block An example object from visiting google.com 8

9 Object Surface Area Calculation (2) Each block starts with its own size as weight Weights are propagated forward with flow Invalid blocks don t propagate Iterate until a fixpoint is reached 2 Compute block with highest weight An example object from visiting google.com 9

10 Nozzle Global Heap Metric Normalize to (approx): P(jumpwill cause exploit) NSA(H) obj build CFG Legend: sub [eax], eax arithmatic adc dh, bh Compute threat of entire heap SA(H) B i memory I/O or syscall control flow add [eax], al add [ecx], 0 outs dx, [esi] or eax, 0d172004h in eax, 0x11 test cl, ah jecxz 021c7fd8 add al, 30h add al, 80h add al, 38h jecxz 021c7fde dataflow xor [eax], eax imul eax, [eax], 6ch or eax, 0d179004h To target block SA(o) Compute threat of single object SA(B i ) 10 Compute threat of single block

11 Nozzle Runtime Heap Spraying Detection Application: Web Browser No ormalize ed Surfac ce Area Malicious Site Nozzle answers: How much of my heap is suspicious? Normal lsite Logical time (number of allocations/frees) 11

12 Thoughts about Nozzle?

13 XFI XFI: Software Guards for System Address Spaces What properties is XFI trying to provide? Instance of a reference monitor Runtime checker that guarantees safety properties What safety properties? XFI = CFI + SFI Control flow integrity (guards on control flow) Software Fault Isolation (guards on data access) XFI slides courtesy Michael Vrable

14 Trustworthy x86 Software Isolation Source Code Compiler Executable Debugging Info Rewriter Safe Executable Works for legacy code C, C++, hand written assembly Verify actual PE binaries Very small TCB Mostly just parsing x86 code Verifier Execution

15 Foundation: Control Flow Integrity Need to know what instruction may execute to verify code as safe, but x86 makes this difficult // ecx == Some jump targets not known until jmp ecx runtime may even point to the middle of an instruction 40000: 05 CF add eax, 1CFh Processor executes code as: CF iretd

16 CFI: Code as Set of Basic Blocks

17 Key idea Compute control flow graph (CFG) for program For each call site, compute all targets Insert guard at each call site Embed unique id at target At call site check that target of call has appropriate id

18 CFI: Example of Instrumentation Original code Instrumented code Jump to the destination only if the tag is equal to Abuse an x86 assembly instruction to insert tag into the binary slide 18

19 Some tricky details What if A calls C and B calls C or D? If we use same tag for C and D then allow A to call D Options: Code duplication Multiple tags per target Similar problem on call return C is called by A and B what tag should written? Allows C to return to B after being called by A Solution? slide 19

20 Note Target bit patterns must be globally unique Does not allow modification i of code at runtime and must not allow execution of code Problems?

21 Execution Environment Code owns small portion of address space Must prevent access to other memory without hardware support Code might be granted access to other memory Other code/data to be protected Isolated code/data Virtual address space 32-1

22 XFI Memory Protection Memory accesses get a runtime bounds check: mov [eax], 100 becomes CFI ensures checks will actually be run cmp eax, jae l1 int 3 l1: cmp eax, jbe l2 int 3 Check lower bound Check upper bound l2: mov [eax], 100 Perform access

23 XFI Stack Protection Further complications result when isolating code in kernel: Stack must alwaysbe valid, have sufficient free space to handle interrupt at any time Shouldn t allow writeaccess to interrupt stack If not true Machine double faults and hlt halts

24 Conventional Stack Use Stack mixes control flow information, data: int f() { ret. addr. int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); esp x y return a + b*z; void h(int *z) { *z = 2; local variables arguments control information i

25 Conventional Stack Use Stack mixes control flow information, data: int f() { ret. addr. int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); esp x y 2 1 return a + b*z; void h(int *z) { *z = 2; local variables arguments control information i

26 Conventional Stack Use Stack mixes control flow information, data: int f() { ret. addr. int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); esp x y 2 1 ret. addr. return a + b*z; void h(int *z) { *z = 2; local variables arguments control information i

27 Conventional Stack Use Stack mixes control flow information, data: int f() { ret. addr. int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); x y 2 1 ret. addr. z return a + b*z; esp &z void h(int *z) { *z = 2; local variables arguments control information i

28 Conventional Stack Use Stack mixes control flow information, data: int f() { ret. addr. int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); x y 2 1 ret. addr. z return a + b*z; &z void h(int *z) { esp ret. addr. *z = 2; local variables arguments control information i

29 Reorganizing the Stack Split stack in two to remove dual use: use: int f() { int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); return a + b*z; void h(int *z) { *z = 2; ebp x y data stack ret. addr. control stack esp

30 Reorganizing the Stack Split stack in two to remove dual use: use: int f() { int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); return a + b*z; void h(int *z) { *z = 2; ebp x y 2 1 data stack ret. addr. control stack esp

31 Reorganizing the Stack Split stack in two to remove dual use: use: int f() { int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); return a + b*z; void h(int *z) { *z = 2; ebp x y 2 1 data stack ret. addr. ret. addr. control stack esp

32 Reorganizing the Stack Split stack in two to remove dual use: use: int f() { int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); return a + b*z; void h(int *z) { *z = 2; ebp x y 2 1 z &z data stack ret. addr. ret. addr. control stack esp

33 Reorganizing the Stack Split stack in two to remove dual use: use: int f() { int x, y; y = g(1, 2); int g(int a, int b) { int z; h(&z); return a + b*z; void h(int *z) { ebp *z = 2; x y 2 1 z &z data stack ret. addr. ret. addr. ret. addr. control stack esp

34 Stack Reorganization: Summary Eliminate data storage on control stack Control stack safety more easily verified ebp x y 2 1 z &z ret. addr. ret. addr. ret. addr. esp data stack control stack

35 Verification Trace executions permitted by CFI Dataflow analysis to determine possible register contents On memory access: statically check access is safe

36 Verification Example cmp eax, jae l1 int 3 eax [0, ] eax [0, ], flags: compare eax, eax [0, 39999] l1: cmp eax, jbe ok int 3 eax [40000, ] eax [40000, ], flags: compare eax, eax [49997, ] eax [40000, 49996] l2: mov [eax], 100 access is safe!

37 Real Code Isn t Linear

38 Simplifying the Verifier Keep verifier simple, move complexity to the rewriter: Code Proof Generation Rewriter inserts hints preconditions on each basic block Verifier: linear checking of hints Increases confidence verifier is correct Safe Code?? Proof Verifier Execution

39 Larger Verification Example precondition: none check eax postcondition: eax safe precondition: none check eax postcondition: eax safe preconditions inserted by rewriter postconditions computed by verifier precondition: eax safe use eax postcondition: none precondition is satisfied code verifies

40 Invalid Code precondition: none check eax postcondition: eax safe precondition: none eax not checked postcondition: none preconditions inserted by rewriter postconditions computed by verifier precondition: eax safe use eax postcondition: none precondition fails code is rejected

41 Control flow Overhead Guard on calls Separate stack for local data Data access Guards on memoryaccesses Instruction and data cache locality Target ids, separate stack How slow is too slow?

42 Thoughts about XFI?

43 For next time A different take on software security Is finding security holes a good idea? Milk or Wine: Does softwaresecuritysecurity improve with age?

Robust Shell Code Return Oriented Programming and HeapSpray. Zhiqiang Lin

CS 6V81-05: System Security and Malicious Code Analysis Robust Shell Code Return Oriented Programming and HeapSpray Zhiqiang Lin Department of Computer Science University of Texas at Dallas April 16 th,