Poseidon: Hardware Support for Buffer Overflow Attacks

security;microarchitecutre;buffer overflow

Vaidyanathan, Anuradha ; Alex G Dean, Committee Member,Frank Mueller, Committee Member,Thomas M Conte, Committee Member,Gregory T Byrd, Committee Chair,Vaidyanathan, Anuradha ; Alex G Dean ; Committee Member ; Frank Mueller ; Committee Member ; Thomas M Conte ; Committee Member ; Gregory T Byrd ; Committee Chair

University:North Carolina State University

关键词: security;    microarchitecutre;    buffer overflow;   

Others  :  https://repository.lib.ncsu.edu/bitstream/handle/1840.16/2403/etd.pdf?sequence=1&isAllowed=y

美国|英语

来源: null

【 摘 要 】

Stack smashing attacks were the most exploited security vulnerability in the past decade, according to CERT. Using a method called stack smashing, a malicious user overflows a buffer in the stack frame, overwriting critical stack state. The return address of the current function, which is saved in the function's stack frame, is overwritten when the buffer overflows. The new return address points to the attacker's code. So, when the function is exited, control is transferred to the attacker's code instead of back to the calling function.A common way to prevent overflow-based stack smashing is to insert bounds checking code or insert sentinel values on the stack, but this requires recompilation. We propose a hardware-based method that does not require recompilation, based on the idea that an attack of this kind produces an unexpected return address. The processor maintains a separate hardware stack, called the shadow stack, and monitors the dynamic instruction stream for subroutine calls and returns. When a call instruction is retired, its return address is pushed on the shadow stack. When a return instruction is retired, the address at the top of the shadow stack is popped and compared to the target of the return instruction. If the addresses differ, then the conventional subroutine call/return semantics have been violated. This may truly be an attack, or it may be a legitimate program construct (e.g., setjmp()/longjmp()) that also violates call/return semantics. Legitimate cases are distinguished from attacks by recording the stack pointer along with the return address at the time of a call: when a subroutine returns, the stack pointer appears consistent in the case of an attack but not in the case of setjmp()/longjmp(). There are three distinct parts to the evaluation of the usefulness and the practicality of this idea. The first part is identifying the generality of this solution. This means that we seek to answer the question: "Do we detect all forms of buffer overflow attacks without raising unnecessary false positives in the case of legal program constructs?" The second part is the actual design details of such a stack and the amount of state that needs to be recorded to facilitate the generality described above. The third part is the actual recovery mechanism that could take the form of exceptions raised that could be further handled by the Operating System. This thesis answers the generality and design questions in entirety while laying a solid basic understanding and initial set of experiments for the recovery scheme that could be utilized.