In computer security, a shadow stack is a mechanism for protecting a procedure's stored return address,[1] such as from a stack buffer overflow. The shadow stack itself is a second, separate stack that "shadows" the program call stack. In the function prologue, a function stores its return address to both the call stack and the shadow stack. In the function epilogue, a function loads the return address from both the call stack and the shadow stack, and then compares them. If the two records of the return address differ, then an attack is detected; the typical course of action is simply to terminate the program or alert system administrators about a possible intrusion attempt. A shadow stack is similar to stack canaries in that both mechanisms aim to maintain the control-flow integrity of the protected program by detecting attacks that tamper the stored return address by an attacker during an exploitation attempt.
Shadow stacks can be implemented by recompiling programs with modified prologues and epilogues,[2] by dynamic binary rewriting techniques to achieve the same effect,[3] or with hardware support.[4] Unlike the call stack, which also stores local program variables, passed arguments, spilled registers and other data, the shadow stack typically just stores a second copy of a function's return address.
Shadow stacks provide more protection for return addresses than stack canaries, which rely on the secrecy of the canary value and are vulnerable to non-contiguous write attacks.[5] Shadow stacks themselves can be protected with guard pages[6] or with information hiding, such that an attacker would also need to locate the shadow stack to overwrite a return address stored there.
Like stack canaries, shadow stacks do not protect stack data other than return addresses, and so offer incomplete protection against security vulnerabilities that result from memory safety errors.
In 2016, Intel announced upcoming hardware support for shadow stacks with their Control-flow Enforcement Technology.[7]
Shadow stacks face some compatibility problems. After a program throws an exception or a longjmp occurs, the return address at the top of the shadow stack will not match return address popped from the call stack. The typical solution for this problem is to pop entries from the shadow stack until a matching return address is found, and to only terminate the program when no match is found in the shadow stack.[3]
A multithreaded program, which would have a call stack for each executing thread, would then also have a shadow stack shadowing each of the call stacks.
See also
editReferences
edit- ^ Delshadtehrani, Leila; Eldridge, Schuyler; Canakci, Sadullah; Egele, Manuel; Joshi, Ajay (2018-01-01). "Nile: A Programmable Monitoring Coprocessor". IEEE Computer Architecture Letters. 17 (1): 92–95. doi:10.1109/LCA.2017.2784416. ISSN 1556-6056.
- ^ "StackShield: A "stack smashing" technique protection tool for Linux". Vendicator.
- ^ a b Sinnadurai, Saravanan; Zhao, Qin; Wong, Weng Fai (2008). "Transparent runtime shadow stack: Protection against malicious return address modifications" (PDF).
- ^ Ozdoganoglu, H.; Brodley, C.; Vijaykumar, T.; Kuperman, B. (2006). "SmashGuard: A Hardware Solution To Prevent Attacks on the Function Return Address" (PDF). IEEE Transactions on Computers. 55 (10): 1271–1285. doi:10.1109/TC.2006.166.
- ^ Szekeres, Laszlo; Payer, Mathias; Wei, Tao; Song, Dawn (2003). "SoK: Eternal War in Memory" (PDF). IEEE Symposium on Security and Privacy: 48–63.
- ^ Chieuh, Tzi-cker; Hsu, Fu-Hau (2001). "RAD: A Compile-Time Solution To Buffer Overflow Attacks". Proceedings 21st International Conference on Distributed Computing Systems. pp. 409–417. doi:10.1109/ICDSC.2001.918971. ISBN 0-7695-1077-9. S2CID 32026510.
- ^ "Control-flow Enforcement Technology Preview" (PDF). Intel Corporation.