PRACTICAL CONTROL FLOW INTEGRITY & RANDOMIZATION FOR BINARY - - PowerPoint PPT Presentation
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
cs-457 Department: Computer Science, University of Crete
Christos Tselas, AM:875 Elisjana Ymeralli, AM:801 Ioanna Ramoutsaki, AM: 812 Vasilis Glabedakis, AM: 2921
¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
Attach label to indirect call: l7 ¡
Check label on function entry points ¡
From Elias Athanasopoulos’ lecture about CS457 – Introduction to Information Systems Security
¨ Control Flow Integrity (CFI): Strong protection
¨ A perception of complexity and inefficiency, ¡ ¨ Performance overhead (average/max: 7.7%/
¨ Compatibility issues ¡
¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
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
¨ 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 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.
¨ 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
Control Transfer Method Transfer Targets Integrity Protection Exceptions user-defined exceptions handlers SafeSEH Direct call/jmp Conditional jump(jo,jz) Targets are fixed in the code DEP , W⊕X Indirect jmp/call In memory function pointers CCFIR Ret instructions On stack return addresses, overflow (ROP , return-to-libc) CCFIR
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
Executable Bits Meaning 27 26 3 2-0 No * * * *** Non-executable section yes 1 * * *** Normal code section yes * * !000 Springboard’s invalid entry yes * 1 000 Springboard’s function pointer stub yes 1 000 Springboard’s sensitive return stub yes 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
¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
Source: http://chao.100871.net
Source: http://chao.100871.net
Rewriting of an indirect call and return Rewriting of a direct call and return
¨ 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
given function can only be made at runtime in this case.
¡
¨ 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
¨ 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
¨ Checks whether a given binary conforms to the
following rules:
¤ Any executable section whose 27th 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
¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
¨ CCFIR was tested with the SPEC CPU2000
benchmark and some browsers to evaluate
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
¨ 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
¨ Above observations show that CCFIR is capable of
protecting all tested binaries with a reasonable
¨ 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
¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ Conclusion
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)
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
¨ CFI ¨ CCFIR Approach ¨ Architecture of CCFIR ¨ Evaluation ¨ Discussion ¨ 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