GNU LibSSP: A history lesson.
What is GNU LibSSP
GNU LibSSP is something like the open-source equivalent of what Windows developers call DEP, or Data Execution Prevention. LibSSP addresses Stack based overflows by inserting Stack Canaries during a function pre-amble, and comparing with a known good value of the stack canary on function exit. The idea being that by placing the guardband before the return address, we can prevent direct code execution by aborting when we see a corrupted canary.
GNU stack protection was first discussed on mailing lists, and via patches, in mid-2001. At the time, only FreeBSD was implementing a stack protection patch. Over the next few years, distributions and packages slowly adopted and adapted the patches, until the current design and implementation of SSP was committed to GNU Glibc/gcc. (Derived from this page and this page).
Additionally, a separate patch (deemed FORTIFY_SOURCE) was added to gcc, and usually lumped in with SSP. This patch adds a lightweight check by the compiler to ensure that common stack-smashing functions (like memcpy, and strcpy) avoid using arguments which will obviously lead to stack overflow.
As with everything in security, GNU LibSSP is no magic bullet. The Stack canaries used must come from somewhere (possibly a random number via rand() OR /dev/random, possibly a fixed value). Additionally, the canary value must be protected from alteration. Finally, we must ensure that the canary is sufficiently difficult to reproduce by a malicious buffer overflow (otherwise, why even bother?). Even worse, LibSSP does nothing to prevent against heap overflows, format string attacks, and any non-stack based exploit. It merely prevents overwrites of the return address frame on the stack.
However, in spite of the above, LibSSP remains a very strong protection for GNU based systems. LibSSP was designed and developed by some of the best and brightest minds in the software world. Clearly, with it being open, and available, quite a bit a scrutiny has been placed on this bit of code.
So, why do we care
LibSSP is one layer in the onion of secure software. Close scrutiny of this layer may reveal potential bypasses, help us design a better system of checks and balances, and give us more overall knowledge of how our system actually works. We may walk away from all of this without a single way of subverting the library. In that case, won't we feel better about it's use? Conversely, if we can find some common scenarios where we can effectively limit its usefulness, perhaps we can design a system which avoids those corner cases as often as possible.
Next