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.

I don't think it's the name...

[funkhauser]

I really don't think the name is the problem. I mean, gcc gets by fine with a rather non-descript name.

It seems like it would be difficult to get a whole lot of developers to move over to this at once, so perhaps that's why it's not catching on? If one major group of developers (Red Hat, Debian, whoever) started using this patch, perhaps their influence could sway others? It's not like the world of M$ where the necessary constant upgrading forces users to switch to technologies that Microsoft thinks are important. (Although buffere overflows are a very important issue, I'm just commenting on the fact that it's Microsoft that pushes the technologies, not the needs of the developers.)

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

Re:This vs. Non-executable Stack?

[btellier]

Basically it's like this:

both OpenBSD's non-exec stack and this new stackguard nonsense protect against one form of of a particular class of vulnerabilities: Stack Based Buffer Overflows. The way these usually work is that by stuffing too much data into a variable you are able to cause the program to overwrite other variables which control what the program will do next. You can, in effect, tell the program to not execute whatever it was going to execute before, but instead execute your code. Typically this is accomplished by putting some low-level machine language inside that original variable you overflowed and then pointing the program to that machine code.

This will fail with obsd's method because you aren't allowed to execute machine code if it lies in the memory region that holds the special variables that control program flow.

This is the most ridiculously trivial of all "protections" to defeat because you can execute machine code from other portions of memory. All you have to do is figure out a way to get the program to, at some point, load that machine code into memory. It might get slightly tricky if it's a remote exploit but when it's a local one you can usually just set an environment variable to some machine code. Since these vars get loaded onto the heap you can simply point the control variable to them and it'll execute anything you want.

This will fail with this new method because between the variable you overflow and the variable that controls program flow there is a random number. Before looking to see where the control variable is pointing to the program will check to see if the random number is the same as it was before the function started. If you overwrote it in order to modify the control variable the program will stop.

Meanwhile this protection won't stop other kinds of buffer overflows, such as .data based overflows and heap overflows that smash memory trees.. that's a bit more complicated though and difficult to describe in layman's terms.