Wednesday, October 22, 2014

Control Flow Integrity (CFI)

Traditionally, arbitrary malicious code execution (e.g. caused by buffer overflow, stack or heap manipulation) is one of major threats in computer security. 

But due to the fact that there are many hardware-enforced security features are introduced in recent processors, for example in my previous post, the attackers are starting to explore the other advanced techniques.

As stated previously, SMEP, NX and W^X enforcement are powerful security features that can significantly prevent malicious code modification and execution. They make traditional attacking methods, like code injection or user arbitrary code execution, extremely harder than ever. 

So, the attackers begin to seek other opportunities like control flow hijacking by misusing the existing machine code execution without code injection to achieve the same or similar malicious behaviors. For example, they can firstly use ROP or JOP to bypass or even completely disable those hardware protections, then they can do whatever they want to do by falling back to traditional ways.  

CFI (Control-Flow Integrity) is an efficient way that can prevent such control flow hijacking attacks from arbitrarily controlling program behaviors. Unlike a legitimate control flow execution in an application, the hijacked control flow (like ROP or JOP) generally has many significant differences, like too many indirect jmp/call/ret instructions, calling a procedure without corresponding ret (or visa versa) , etc. 

However, implementing a high-performance and efficient solution with CFI is not easy. It may require software code or binary changes, it may require compiler changes or even require hardware/processor support. 

This post won't propose any solution about CFI implementation(though I indeed have one recently, but cannot public it right now), just share some papers I read more recently. 

References for CFI, ROP, JOP:

See my post for my solution of defending ROP/JOP with CFI.

No comments:

Post a Comment