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:
-------------------------------------
Update:
See my post for my solution of defending ROP/JOP with CFI.
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:
-------------------------------------
- Control-flow integrity principles, implementations, and applications: http://www.utd.edu/~hamlen/Papers/ccs05-cfi.pdf
- CFIMon: Detecting violation of control flow integrity using performance counters: http://adl.csie.ncu.edu.tw/adlab/ppt/456_CFIMon.pptx
- Return-oriented programming without returns: https://www.cs.jhu.edu/~s/papers/noret_ccs2010/noret_ccs2010.pdf
- blackhat08--ROP-without-code-injection: https://cseweb.ucsd.edu/~hovav/dist/blackhat08.pdf
- hardware-assisted-cfi: https://www.informatik.tu-darmstadt.de/fileadmin/user_upload/Group_TRUST/PubsPDF/hardware-assisted-cfi.pdf
- Kbouncer (LBR MSR): http://www.cs.columbia.edu/~vpappas/papers/kbouncer.sec13.pdf
- ROPecker: http://www.mysmu.edu/phdis2008/yqcheng.2008/ROPecker-NDSS14.pdf
- ROPStop: ftp://ftp.cs.wisc.edu/paradyn/papers/Jacobson14ROPStop.pdf
- ROPdefender: https://www.cs.jhu.edu/~s/teaching/cs460/2012-fall/ROPdefender.pdf
- Nicholas Carlini, David Wagner, ROP is Still Dangerous: Breaking Modern Defenses
http://www.cs.berkeley.edu/~daw/papers/rop-usenix14.pdf - Enes Gökta¸s, Size Does Matter - Why Using Gadget-Chain Length to Prevent Code-Reuse Attacks is Hard
http://www.cs.columbia.edu/~mikepo/papers/chainlength.sec14.pdf - Binary Analysis Platform, (BAP from CMU):
http://bap.ece.cmu.edu/ - Out Of Control: Overcoming Control-Flow Integrity: http://www.ieee-security.org/TC/SP2014/papers/OutOfControl_c_OvercomingControl-FlowIntegrity.pdf
Update:
See my post for my solution of defending ROP/JOP with CFI.
No comments:
Post a Comment