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
Outline ¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
CFI Check label on function entry points ¡ Attach label to indirect call: l7 ¡ From Elias Athanasopoulos’ lecture about CS457 – Introduction to Information Systems Security
¨ 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.
Outline ¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
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
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
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 .
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
Protection Targets Control Transfer Transfer Targets Integrity Protection Method Exceptions user-defined SafeSEH exceptions handlers , W ⊕ X Direct call/jmp Targets are fixed in DEP Conditional jump(jo,jz) the code Indirect jmp/call In memory function CCFIR pointers Ret instructions On stack return CCFIR addresses, overflow (ROP , return-to-libc)
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
Distinguishable Targets Bits Executable Meaning 27 26 3 2-0 No * * * *** Non-executable section yes 1 * * *** Normal code section yes 0 * * !000 Springboard’s invalid entry yes 0 * 1 000 Springboard’s function pointer stub yes 0 1 0 000 Springboard’s sensitive return stub yes 0 0 0 000 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
Outline ¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
Architecture of CCFIR Source: http://chao.100871.net
Background: Relocation Table
BitCover Source: http://chao.100871.net
BitRewrite Rewriting of an indirect call and Rewriting of a direct call and return return
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
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
Problem 2 ¨ When an unprotected module calls a protected function, a false alarm is triggered by the protected function when it tries to return
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
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
Solution ¨ Bit Rewrite generates a read-only and non- executable wrapper to replace it
¨ 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.
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
Security Enforcement and Randomization ¨ For security enforcement two extra layers of protection are added: Sensitive Functions cannot be called via direct 1. calls/CCFIR raises alert in different case CCFIR introduces randomization in the order of 2. stubs
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
Outline ¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
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
Performance Of Static Analysis
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
Performance overhead brought by CCFIR
¨ Above observations show that CCFIR is capable of protecting all tested binaries with a reasonable overhead
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
Protection against real world exploits
Outline ¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
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)
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
Recommend
More recommend
