Stack-Smashing Protector 28
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."
This vs. Non-executable Stack? (Score:2, Interesting)
Re:This vs. Non-executable Stack? (Score:4, Informative)
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
Re:This vs. Non-executable Stack? (Score:2)
It's executable,
and or
Read/Writable.
So if the stack/heap was set to R+W not but X
and the main application set to X but not R+W, then bufferover flows(or self modifying code)
would never be possible
The problem is that most kernels are tooo crap to handle this properly or to put it another way, the kernel doesn't provide sufficent architecture to allow you to write all of your code that way.
Re:This vs. Non-executable Stack? (Score:2)
What if your code, as a fun optimization or hack, wants to store executable code in a variable and execute the code stored in the variable?
Should we disallow an entire class of actions because people are too stupid and lazy to check the length of their data before they write it to memory?
Justin Dubs
app allocates memory (Score:2)
The kernel should provide the architecture so that the application never has to do any of this stuff, all relocation etc... should be handled by the kernel and not the application.
If the kernel does all of this then you can say that the operating system is secure to buffer overrun exploits, the apps will still crash though and could be comprimised in other ways.
Ring 0(should only be the kernel) can change the W+R+X of a memory address if it want's to.
Re:This vs. Non-executable Stack? (Score:2)
Granted, this would severely narrow the window that the Phrack article mentioned, (it talked about overwriting function pointers in the GOT, which in your scheme would presumably be on a read-only page) but so long as buffers are overrunable, there will be some code that experiences some type of exploit.
Looking at the patch, it doesn't seem that this patch fully addresses this issue - it deals with reordering local variables to avoid some of the less desireable effects of overruns, but what about function pointers stored in classes or structs? Those can't be reordered.
Re:This vs. Non-executable Stack? (Score:1)
Of course you probably want to modify the function pointer's value, so it has to be in writable memory, thus the kernel has really no way to protect it. So it doesn't have to be on the heap, but that doesn't help you much.
Re:This vs. Non-executable Stack? (Score:2)
While function pointers are the most flexible variable used in determining execution flow, even in a scenario without a writeable GOT or any function pointers (which would require major redesign of at least libc and gcc), you may still be in trouble. As long as a variable that can be overwritten is used in a decision (i.e. if or switch) or as an array index a buffer overrun can affect the program flow. For example, it might be possible in some poorly written program to overwrite some piece of the program's configuration information through a complicated buffer overflow attack - many of even the most secure programs can be made insecure by a bad configuration.
The only absolute solution to containing the potential damage from buffer overflows is to avoid buffer overflows altogether. Each of these steps simply minimizes the number of ways to exploit buffer overruns, which raises the bar and may even shrink the pool of potentially exploitable programs.
There's a kenel solution to this (Score:1)
If you can't write directly into the application, and you can't redirect the application to execute outside it's requested space. Then it becomes very difficult to get those m$ type exploits.
I think Microsoft is doing something like this with paladium? (I only said like mind you!)
The kernel is responsible for loading executables
You can request access mode change for a page of memory from the kernel.
The Kernel won't permit the applications EIP be in pages that the application hasn't requested access for.
when you malloc you request your access mode.
This kinde of model also helps threading,because the kernel knows where self modifying code is, where read-only pages are etc... and can make far better use of caches and page flushes between threads.
Re:This vs. Non-executable Stack? (Score:1)
Re:This vs. Non-executable Stack? (Score:2, Informative)
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.
Microsoft Visual C++ .NET has a similar feature (Score:5, Informative)
The
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:Microsoft Visual C++ .NET has a similar feature (Score:2)
Re:Microsoft Visual C++ .NET has a similar feature (Score:1, Interesting)
True it was hyped as an exploit when it really isn't, but it goes to show that there is no replacement for skilled and careful coding.
See http://www.cigital.com/news/mscompiler-tech.html [cigital.com] for more info.
Jesse
Re:Microsoft Visual C++ .NET has a similar feature (Score:2, Interesting)
How is this determination made? Is it just looking for functions that make certain calls, or what?
Seems to me all the attacker has to do is figure out how to spoof the security cookie. What prevents this?
Not quite (Score:2)
If you read the phrack article linked to in the story, they discuss situations where this manner of buffer overrun protection is insufficient. True, most exploits out there today do use straight overruns onto the return address, but that's only because they can.
That being said, I imagine that the conditions described in the phrack article for getting a manipulable pointer are less common than the authors would like to think.
Heh (Score:1, Funny)
I don't think it's the name... (Score:4, Interesting)
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.)
Re:I don't think it's the name... (Score:2)
Re:I don't think it's the name... (Score:2)
You also have to consider that gcc is the only option on most non-Windows systems. GNU could rename it "FUA" and people would still use it.
Many developers just don't want it (Score:5, Interesting)
dan
Re:Many developers just don't want it (Score:3, Interesting)
Why does the Linux kernel set the exec flag for stack pages? I don't see any reason why it should. If the program needs to load code, then it can just use one of the lower level calls to allocate the memory as executable. Pages used only for storing data should not be executable. I think I'll try to find this patch...
Re:Many developers just don't want it (Score:2)
The problem, of course, occurs when a program trusted with security responsibilities contains a bug. In such cases, the answer is to fix the bug. This is not, and should not be, the kernel's responsibility.
Having said that, if you want to apply the non-executable stack patch because you don't trust your "trusted" programs, go ahead. :-)
g++ write/wrote code on the stack (Score:2)
Some other (Lisp?) compilers use similar tricks.
Re:nested functions (Score:2)
I didn't realize there were so many programs still using stuff like self modifying code and code on the stack. I thought that was old school stuff.
As for trampolines, the kernel patch I found has a work around to emulate them. It also allows you to set a flag in the executable so that if they need exec on the stack, you can configure it.
The patch is a part of the Openwall Project [openwall.com]. That patch also has some other apparently useful security features. Too bad it lags the kernel development in a big way...
Re:Many developers just don't want it (Score:2)
Executing code on the stack isn't unheard of in legitimate programs--it's sometimes used for performance reasons and sometimes to simplify implementation. Usually it's done in cases where the program's control flow is somewhat complicated:
* Linux puts signal handlers on the stack. They need to be executable.
* Kaffe and other vms put code on the stack for efficiency reasons.
* Many functional programming languages write code on the stack for performance reasons.
* Some garbage collectors write code on the stack
* Some user-space threading libraries put code on the stack
I'm sure there are others. I know Solar Designer's noexec stack patch had some workarounds for gcc's trampolines, I'm not sure if they worked with everything or not.
Sumner
It should be bundled with GCC (Score:2)
It is much easier to convince someone to use a specific flag, than to install a third party patch. The later takes more time, and require you to trust more people.