Stack-Smashing Protector

XNormal writes "It's not exactly new but for some reason it doesn't seem to be getting the attention it deserves. The stack smashing-protector developed by Hiroaki Etoh at IBM's Tokyo Research Lab is a patch for GCC that provides effective protection against buffer overflows. It protects against cases not covered by StackGuard and StackShield. It it well-supported on multiple versions of GCC and multiple platforms. Why is it not getting enough attention? Perhaps it needs a CatchyName instead of 'ssp'? I'll ponder this question while I'm recompiling all my executables that have an open port and the libraries they depend on."

Comments

Microsoft Visual C++ .NET has a similar feature

[cpeterso]

Microsoft Visual C++ .NET (aka MSVC7) has a similar feature called Buffer Security Check. This is for "unmanaged" C++ code, not C#/.NET/CLR code. This new compiler option /GS is on by default.

/GS (Buffer Security Check)

The /GS option is used to detect buffer overruns, which overwrite the return address -- a common technique for exploiting code that does not enforce buffer size restrictions. This is achieved by injecting security checks into the compiled code.

On functions subject to buffer overrun problems, the compiler will allocate space on the stack before the return address. On function entry, the allocated space is loaded with a security cookie that is computed once at module load. Then, on function exit, a compiler helper is called to make sure the cookie's value is still the same. If the value is not the same, an overwrite of the return address has potentially occurred, and so an error will be reported and the process (or at least the thread) terminated.

Many developers just don't want it

[maeglin]

The reason stack protection stuff isn't being widely used isn't because it's got an obscure name or something simple like that. It's because not everyone can agree whether it's effective or just lures people into a false sense of security. There have been a couple of "discussions" of this on the Linux Kernel Mailing List and the end result is always a stalemate.

dan