PRACTICAL CONTROL FLOW INTEGRITY & RANDOMIZATION FOR BINARY EXECUTABLES

Transcription

1 PRACTICAL CONTROL FLOW INTEGRITY & RANDOMIZATION FOR BINARY EXECUTABLES Christos Tselas, AM:875 Elisjana Ymeralli, AM:801 Ioanna Ramoutsaki, AM: 812 Vasilis Glabedakis, AM: 2921 cs-457 Department: Computer Science, University of Crete

2 Outline CFI CCFIR Approach Architecture of CCFIR Evaluation Discussion Conclusion

3 CFI Check label on function entry points Attach label to indirect call: l7 From Elias Athanasopoulos lecture about CS457 Introduction to Information Systems Security

4 Control Flow Integrity (CFI): Strong protection against modern control-flow hijacking attacks. However: A perception of complexity and inefficiency, Performance overhead (average/max: 7.7%/ 26.8%) and Compatibility issues limit its adoption.

5 Outline CFI CCFIR Approach Architecture of CCFIR Evaluation Discussion Conclusion

6 CCFIR CCFIR: New practical and realistic protection method against control flow hijacking attacks,which enforce CFI method. Collects all legal targets of indirect control-transfer instructions (call/jump/ret), puts them into a Springboard section in a random order, encodes target restrictions via code alignment and then limits indirect transfers to flow only to them Distinguishes between calls and returns Prevents unauthorized returns into sensitive functions (e.g. system()) Low performance overhead Compatible with unmodified legacy binaries Does not depend on source code or debug information

7 CCFIR Advantages Robust protection: against return-to-libc and ROP On-site randomization: randomize the order of stubs in Springboard at load-time High performance: low overhead 3.6%/8.6% (average/max) Binary only: no source code or debug symbols Progressive deployment: compatibility between protected and unprotected code

8 CCFIR Approach CCFIR improves CFI as it separates: Function pointers Sensitive return addresses Non-sensitive return addresses This happens in the Springboard section layout without requiring separate ID values and checks. This stops the jumps that would be most useful to attackers.

9 Assumptions ASLR and W X (such as DEP) are in use No self-modifying code or dynamically generated code Limited information disclosure vulnerabilities attackers cannot read entire memory regions

10 Protection Targets Control Transfer Method Exceptions Direct call/jmp Conditional jump(jo,jz) Transfer Targets user-defined exceptions handlers Targets are fixed in the code Integrity Protection SafeSEH DEP, W X Indirect jmp/call Ret instructions In memory function pointers On stack return addresses, overflow (ROP, return-to-libc) CCFIR CCFIR

11 Springboard Section A code section is split up into 2 sections, and all indirect control Transfers are only permitted to flow to an Aligned address in the Springboard section

12 Distinguishable Targets Executable Bits Meaning No * * * *** Non-executable section yes 1 * * *** Normal code section yes 0 * *!000 Springboard s invalid entry yes 0 * Springboard s function pointer stub yes Springboard s sensitive return stub yes Springboard s normal return stub q Entries in the Springboard are all aligned. (0-2 bits) q Three kinds of stubs in Springboard q Function pointer stub entries vs. ret-stub entries (3rd bit) q sensitive vs. normal ret-stub (26th bit) q Function pointer stubs: 8-byte aligned/return address stub: 16-byte aligned. q normal ret-stubs cannot return into the middle of sensitve functions q One or two bit testng instructons are sufficient to validate its target

13 Outline CFI CCFIR Approach Architecture of CCFIR Evaluation Discussion Conclusion

14 Architecture of CCFIR Source:

15 Background: Relocation Table

16 BitCover Source:

17 BitRewrite Rewriting of an indirect call and return Rewriting of a direct call and return

18 Compatibility Issues A protected module only allows indirect control transfers whose targets are valid springboard stubs so an indirect control transfer from a protected to an unprotected module will fail If every module is rewritten the separate modules will be compatible however : Rewriting all modules is not always possible

19 Problem 1 An external function that is not exported by any external module can be called(through an object of an unprotected library) The check will fail in the protected module because the function pointer is not in the Springboard

20 Problem 2 When an unprotected module calls a protected function, a false alarm is triggered by the protected function when it tries to return

21 Solution We run BitCover on all libraries which can possibly be loaded by a protected module A hash table is built from these valid code pointers When an error happens because of a failed check, the error handler looks up the hash table as a final chance to find the target Hash table is seldom used

22 Problem 3 Most calls to external functions are done through imported function pointers which are stored in the import address table Imported function pointers will be resolved at load time and the IAT entries are updated We can t statically modify these entries

23 Solution Bit Rewrite generates a read-only and nonexecutable wrapper to replace it

24 Problem 4:Some dynamic libraries are loaded and linked at run-time and their function pointers are obtained by GetProcAddress. The address of a given function can only be made at runtime in this case.

25 Solution We leave stubs in the Springboard which can be filled runtime Wrapper calls original GetProcAddress function and fills the new stub with the address Only the page containing this stub in the Springboard is writable for the time of this update

26

27 Security Enforcement and Randomization For security enforcement two extra layers of protection are added: 1. Sensitive Functions cannot be called via direct calls/ccfir raises alert in different case 2. CCFIR introduces randomization in the order of stubs

28 BitVerify Checks whether a given binary conforms to the following rules: Any executable section whose 27 th bit is zero is in Springboard section Code stubs in Springboard section are all aligned Function pointers are rewritten and redirected to the springboard section All call instructions have been rewritten to make sure the pushed return address points to the Springboard section Dynamic checks have been inserted before all indirect instructions

29 Outline CFI CCFIR Approach Architecture of CCFIR Evaluation Discussion Conclusion

30 Evaluation CCFIR was tested with the SPEC CPU2000 benchmark and some browsers to evaluate overhead and protection. A.Performance CCFIR is used to automatically disassemble and rewrite 26 benchmark binaries Scripts check that the new binaries have the same behavior and output as the original ones Windows 7 32-bit and Inter Core2 Duo CPU 3.00 GHz were used for the experiments

31 Performance Of Static Analysis

32 Performance of Load-Time Randomization Bootstrap code is placed in the protected executable to accomplish load-time randomization Results show that load time randomization is achieved in a very small amount of time It takes about 16 milliseconds for 1M memory movement

33 Performance overhead brought by CCFIR

34 Above observations show that CCFIR is capable of protecting all tested binaries with a reasonable overhead

35 B.Protection effects Randomization entropy Load time randomizations makes it hard to guess the address of a target function Makes a brute-force search infeasible as there are 2^23 possible positions in a 128 MB springboard Protection against real world exploits Some vulnerable modules(e.g xul.dll) were hardened with CCFIR and attacks were prevented

36 Protection against real world exploits

37 Outline CFI CCFIR Approach Architecture of CCFIR Evaluation Discussion Conclusion

38 Discussion A.Possible Attacks To attack CCFIR an attacker may: a) Forge a valid target(the attacker has to use a page which is writable and executable) b) Change memory pages protection attributes(some APIs are disable page protections but CCFIR raises an alert if such functions are called.even if a function makes a page executable the attacker must also penetrate the randomization) c) Jump to valid targets or chain them to launch attacks(attackers abilities for this attack are greatly constrained.call/jmp flow only to valid entry points)

39 Discussion B.Race condition of return address CCFIR checks value of esp and then executes ret in the next instruction Return address is stored in memory in the interim and it can be modified by another thread The time window is so small that the odds of a successful attack is extremely small

40 Outline CFI CCFIR Approach Architecture of CCFIR Evaluation Discussion Conclusion

41 Conclusion CCFIR is used to ensure that indirect control transfers jump only to safe targets It extends and enforces CFI Blocks various attacks including ROP attacks and return-into-libc Solves the performance and compatibility issues of CFI while its runtime overhead remains low

42 Thanks!!!