1

I would like to know why nowadays Stack Guard is used everywhere (example: ProPolice in GCC, /GS in Visual Studio), instead of Stack Shield.

Both the approaches (i.e. Stack Guard & Stack Shield) provide an equal level of security.

Any specific advantages of Stack Guard over Stack Shield ?

Improve this question

1 Answer 1

Reset to default
2

These technologies are similar in that they are compiler protections. To get protection, an application needs to be recompiled, but the source code does not need to be changed (at least, unless the app does something funky, like self-modifying code)

Stack Guard is based on a "canary" value that is put on the stack with each function call. At the end of the function, the canary is checked. If an overflow has occurred, this will corrupt the canary and will be detected.

Stack Shield is based on copying the return address to a safe area, and checking the return address at the end of the function. If the return address is overwritten, this will no longer match and the attack will be detected.

Because they work differently, they have slightly different security properties. In particular, Stack Guard is better at detecting corruption of things other than the return address. And this is why Stack Guard is more widely used.

This paper is interesting: http://www.coresecurity.com/files/attachments/StackGuard.pdf

Improve this answer
5
  • 1
    Can you please elaborate on how 'Stack Guard is better at detecting corruption of things' ?
    – Jaydeep Solanki
    Oct 20, 2013 at 14:04
  • "things other than the return address" for example, if the overflow overwrites the return address, but sets it to its correct value, then overwrites a function pointer in the next stack frame maliciously - then Stack Guard will detect that but Stack Shield will not
    – paj28
    Oct 20, 2013 at 14:25
  • But then that would be detected in the previous function in the stack.
    – user32263
    Oct 21, 2013 at 10:55
  • "things other than the return address" for example, if the overflow overwrites the return address, but sets it to its correct value, then overwrites a function pointer in the next stack frame maliciously - then Stack Guard will detect that but Stack Shield will not" --> Yes but then the control flow will redirect eip to previous function as in normal execution and this one function would probably validate it's own stack frame ret address, detecting the problem...
    – user32263
    Oct 21, 2013 at 12:15
  • This link suggests otherwise: phrack.org/issues.html?issue=56&id=5#article
    – paj28
    Oct 21, 2013 at 12:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .