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.

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.

Re:This vs. Non-executable Stack?

[Anonymous Coward]

This approach catches a different variation of buffer overflow attacks. Basically, the stack of a function holds information local to that function, such as its data and where to go(return) when the function completes.

Stack attacks are possible when a function allocates a fixed amount of data on the stack for input, and more data is stored than fits in this buffer. The extra data could then overwrite all kinds of data following the buffer.

This protection mives the buffer(s) to the last position in the stack. This will protect the return address of the function. Even if the attacker manages to put (executable) code in this buffer, he is unable to reach it. He's also unable to jump to existing sensitive areas in your code.

In comparison, the non-executable stack protection allows you to reach that code but the moment you reach it the OS faults your program.
It can't protect you against existing code in your program.