Prac%cal Control Flow Integrity & Randomiza%on for Binary Executables

Transcription

1 Prac%cal Control Flow Integrity & Randomiza%on for Binary Executables Chao Zhang Tao Wei Zhaofeng Chen Lei Duan Peking University Peking University UC Berkeley Peking University Peking University László Szekeres Stephen McCamant Dawn Song Wei Zou Stony Brook University University of Minnesota UC Berkeley Peking University

2 Eternal War in Memory (Oakland 13) buffer overflow A t t a c k e r code injec%on 2libc, ROP code re- use Info Leakage W X ASLR? D e f e n d e r 2

3 Reac%ve Defense is not adequate > 5,000 CVE vulnerabili%es each year. Many more are under the iceberg. Vulnerabili%es are exploited millions of %mes. 7,000 6,000 5,000 4,000 3,000 2,000 1,000 #cve Symantec Internet Security Threat Report 3

4 Proac%ve Defense: Control Flow Integrity Control Flow Integrity, CFI [CCS 05] Security policy Each run- %me control transfer must comply with programmer s compile- %me intent, i.e., the control- flow graph A strong guarantee that can be reasoned about formally ROP, JOP, UAF A founda%on for other low- level code defenses SFI, sandboxing untrusted code Determinis%c, not probabilis%c defense 4

5 Control- Flow Graph condi%onal jump (jz ): target rela%ve address direct jump/call: target rela%ve or absolute address indirect jump/call: target? (read or computed from memory) urn: target urn address on the stack 5

6 Scope of Control- Flow Integrity Protec%on Control Transfer Method Transfer Targets Integrity Protec8on Excep%ons Excep%on handlers SafeSEH, SEHOP Direct CALL/JMP, Condi%onal jump (JZ) Hard- coded func%on pointers (embedded in the code) W X Indirect CALL/JMP In- memory func%on pointers CFI RET instruc%ons On- stack urn addresses /GS, shadow stack, CFI 6

7 Control Flow Integrity (CCS 05) call eax next_1: call ecx next_2: foo: bar: fun: build Control Flow Graph source code/debug info all modules 7

8 Control Flow Integrity (CCS 05) check ID_1 call eax next_1: call ecx next_2: foo: ID_1 bar: fun: build Control Flow Graph binary rewri%ng instrument IDs before transfer targets validate IDs before control transferring 8

9 Control Flow Integrity (CCS 05) check ID_1 call eax next_1: check ID_1 call ecx next_2: foo: ID_1 bar: ID_1 fun: ID_1 build Control Flow Graph binary rewri%ng diversity of IDs 9

10 Control Flow Integrity (CCS 05) check ID_1 call eax ID_2 next_1: check ID_1 call ecx ID_2 next_2: foo: ID_1 check ID_2 bar: ID_1 check ID_2 fun: ID_1 check ID_2 build Control Flow Graph binary rewri%ng diversity of IDs all indirect transfers indirect call indirect jmp 10

11 Challenges faced by CFI performance overhead: average 15%, max 46% check ID_1 call eax next_1: call foo foo: ID_1 Ø ID is embedded in a slow prefetchnta instruc%on Ø executed each %me the transfer target is reached Ø introduce overhead even if foo is called/jumped to directly ü most calls/jumps are direct 11

12 Challenges faced by CFI performance overhead modularity support A single module cannot be hardened independently module_a call printf ID_A module_b call printf ID_B libc printf: check which ID? 12

13 Challenges faced by CFI performance overhead modularity support backward compa%bility hardened module check ID_1 call eax next_1: foo: ID_1 bar: ID_1 unhardened module test: 13

14 Challenges faced by CFI performance overhead modularity support backward compa%bility source code/debug info dependency to build Control Flow Graph 14

15 Mo%va%on A light- weight CFI solu%on with a strong protec%on performance overhead modularity support backward compatibility source code independent 15

16 Assump%on ASLR and W X (e.g. DEP) are deployed NO self-modifying code or dynamically generated code. Limited informa%on disclosure vulnerabili%es e.g., cannot read en%re memory regions 16

17 Outline Mo%va%on Intui%on & Design Implementa%on Security Enhancement Evalua%on Conclusion 17

18 Intui%on Checking transfer targets kind, rather than IDs indirect call/jmp can only transfer to func%on- pointer stubs urns can only transfer to urn- address stubs 18

19 Intui%on: efficient check memory alignment func%on pointer stubs are 8- bytes aligned urn address stubs are 16- bytes aligned foo: test [esp],0x0f test eax,7 call eax next_1: bar: test [esp],0x0f test ecx,7 fun: call ecx test [esp],0x0f next_2: fast bit tes%ng performance overhead No IDs performance overhead only check type modularity support 19

20 Intui%on: security Transfer targets must be within memory region Springboard 27 th bit is 0 foo: test [esp],m_r test eax,m_f call eax next_1: bar: test [esp],m_r test ecx,m_f call ecx next_2: M_F = 0x fun: test [esp],m_r M_R = 0x f Policy: all indirect transfer targets must be aligned stubs in Springboard. 20

21 Design: Memory layout with Springboard Executable? Bits Springboard vs. normal code sec%on (27 th bit) Entries in the Springboard are all aligned. (0-2 bits) Three kinds of stubs in Springboard fp- stub entries vs. - stub entries sensi%ve vs. normal - stub Meaning No * * * *** Non- executable sec%on Yes 1 * * *** Normal code sec%on Yes 0 * *!000 Invalid entry in Springboard Yes 0 * fp- stub entry in Springboard Yes Sensi%ve - stub entry in Springboard Yes Normal - stub entry in Springboard (3 rd bit) (26 th bit) normal - stubs cannot urn into the middle of sensi%ve func%ons One or two fast bit tes%ng instruc%ons are sufficient 21

22 Architecture of our solu%on: CCFIR Find out all indirect transfer instruc%ons and their targets BitCover: disassemble target binary Redirect transfer targets to aligned stubs in Springboard Validate transfer targets BitRewrite: binary rewri%ng Verify the hardened binary BitVerify 22

23 Outline Mo%va%on Intui%on & Design Implementa%on Security Enhancement Evalua%on Conclusion 23

24 BitCover: disassembling Target: normal binaries generated by modern compilers Support ASLR On Windows, it implies the executable contains reloca%on informa%on We can iden%fy all legal func%on pointers (indirect call/jmps targets) Automa%cally disassemble most of normal binaries Based on well- defined rules performance overhead modularity support backward compatibility source code independent More accurate than IDA Pro, especially designed for binary rewri%ng 24

25 BitRewrite: binary rewri%ng Policy: all indirect transfers are enforced to aligned stubs in Springboard. Original code section mov eax, 5 1 call eax 2 5 Protected code section mov eax, 5 1 call eax 2 5 Validate s target. - stub in Springboard validate 6 3' Direct control transfer Indirect control transfer Springboard section 25

26 BitRewrite: binary rewri%ng Policy: all indirect transfers are enforced to aligned stubs in Springboard. Original code section Protected code section mov eax, 5 mov eax, call eax ' 5 validate 6 Validate s target. - stub in Springboard Redirect s target. move call to Springboard 2'' call eax 3' Direct control transfer Indirect control transfer Springboard section 26

27 BitRewrite: binary rewri%ng Policy: all indirect transfers are enforced to aligned stubs in Springboard. Original code section Protected code section mov eax, 5 mov eax, call eax 6 1 2' 3 4 2'' validate call eax validate 5 6 Validate s target. - stub in Springboard Redirect s target. move call to Springboard Validate call s target. fp- stub in Springboard 3' 5' Direct control transfer Indirect control transfer Springboard section 27

28 BitRewrite: binary rewri%ng Policy: all indirect transfers are enforced to aligned stubs in Springboard. Original code section Protected code section mov eax, 5 mov eax, 5' call eax '' 3' 5' 1 2' 5 validate call eax validate 6 Validate s target. - stub in Springboard Redirect s target. move call to Springboard Validate call s target. fp- stub in Springboard Redirect call s target. rewrite func%on pointers Direct control transfer Indirect control transfer Springboard section 28

29 BitRewrite: In a nutshell redirect func%on pointers and urn addresses rewrite func%on pointers in memory move call instruc%ons to springboard validate transfer targets with bit tes%ng instruc%ons mov eax,foo call eax next: foo: mov eax,foo_sb foo: test eax,8 jz error test eax,m_f jnz error jmp next_sb- 2 next: test [esp],m_r jnz error call eax next_sb: jmp back foo_sb: jmp foo Direct control transfer Indirect control transfer M_F = 0x M_R = 0x800000f or M_R = 0xC00000f 29

30 BitRewrite: Op%miza%ons performance overhead modularity support backward compatibility source code independent With the support of W X, we can skip redirecting or validating directly used func%on pointers call foo directly used imported func%ons call [imp_foo] switch statements and jump table jmp jump_table[eax*4] 30

31 BitRewrite: backward compa%bility performance overhead modularity support backward compatibility source code independent With a full deployment (i.e., all modules hardened), backward compa%bility issues no longer existed. With incremental deployment, such issues occur when CALL/JMP to func%ons in unhardened modules RET to urn addresses in unhardened modules 31

32 case 1: Imported func%ons Challenge Import Address Table (IAT) load- %me resolving the loader will update IAT we cannot sta%cally rewrite IAT entries (func%on pointers) Solu%on Replace IAT with a wrapper table mov ecx,[foo_slot] call ecx mov ecx, [foo_slot_wrap] call ecx.iat: foo_slot:.iat: foo_slot: foo points to foo IAT_wrapper foo_slot_wrap: foo_sb Springboard foo_sb: jmp [foo_slot] points to 32

33 case 2: Func%ons resolved by GetProcAddress Challenge GetProcAddress() urns a non- redirected func%on pointer. The instrumented security check will fail Solu%on wrapper for GetProcAddress redirect urn value at run%me mov ecx,[gpa_slot] call ecx call eax ;GPA s value mov ecx, [gpa_slot_wrap] call ecx call eax ;GPA s value IAT_wrapper gpa_slot_wrap: gpa_sb.iat: gpa_slot: GetProcAddress.iat: gpa_slot: GetProcAddress Springboard points to gpa_sb: jmp gpa_wrapper gpa_wrap: call [gpa_slot] #fill new stub # stub ptr points to 33

34 BitVerify: Offline Verifica%on whether a given binary conforms to security rules? 27 th bit of executable sec%on except Springboard should be 1 Code stubs in Springboard are all aligned Func%on pointers are redirected Call instruc%on has been redirected Check code has been correctly inserted 34

35 Outline Mo%va%on Intui%on & Design Implementa%on Security Enhancement Evalua%on Conclusion 35

36 Policy 1: Restrain sensi%ve func%ons Sensi%ve func%ons system(), execv(), VirtualProtect(), VirtualAlloc(), Policy: Sensi%ve func%ons should be used via direct calls. i.e., their addresses are never taken except hard-coded in instruc%ons Benefit: NO fp- stubs for sensi%ve func%ons in the Springboard Avackers cannot indirectly call/jump to these func%ons. 36

37 Policy 2: Load- %me Randomiza%on Policy: The order of all stubs in the Springboard are randomized at load- %me. Benefit: cannot guess one stub s address even if another address is leaked in the Springboard. A stronger randomiza%on than ASLR. It provides an extra layer of protec%on from the previous CFI- style checking. 37

38 Brief Security Analysis urn- to- libc libc system(): printf(): NO - stub for system() - stub for printf() is randomized jump- to- libc similar to urn- to- libc gadgets must start from fp- stubs in the Springboard ROP Valid gadgets must start from - stubs in the Springboard Few valid ROP gadgets much longer, hard to chain. foo(): test [esp], (info leakage is needed) 38

39 Outline Mo%va%on Intui%on & Design Implementa%on Security Enhancement Evalua%on Conclusion 39

40 Run%me Overhead SPECint2000, average 3.6%, max 8.6% SPECfp2000, average 0.59%, max 3.98% 40

41 Sta%c Analysis Time SPECint2000 & SPECfp2000, 10s seconds 41

42 ROP Elimina%on Mona is used to count ROP gadgets Valid gadgets must start from - stubs in Springboard SPECfp2000 App original #gadgets new #gadgets valid #gadgets wupwise swim mgrid applu mesa galgel art equake facerec ROP gadgets count (part) 42

43 Real World Exploits Protec%on 43

44 Outline Mo%va%on Intui%on & Design Implementa%on Security Enhancement Evalua%on Conclusion 44

45 Conclusion Performance and compa%bility issues limit the adop%on of Control Flow Integrity. CCFIR is a lightweight CFI solu%on providing a strong guarantee, can block control- flow hijacks like ROP and 2libc. CCFIR overcomes the performance and compa%bility issues, and make it a prac%cal solu%on. 45

46 Thanks! 46