Stack Ghost

Hi everyone.

Imagine a way of programing and be able to say 100% security against buffer overflows????

Sounds to good to be true doesnt it ;)

Since buffer overflows have todo with data going into the memory, think what if that data would be encrypted?

Im no good in explaining this, so lemme quote it a bit.

Quote:

---

StackGhost


Authors: Mike Frantzen
Mike Shuey

Download: OpenBSD 3.0 -CURRENT diff

Description: StackGhost is a patch to the OpenBSD kernel for the Sparc architecture. StackGhost transparently and automatically protects applications' stack frames; more specifically, it guards the return pointers. The protection mechanisms require no application source or binary modification and imposes only a negligible performance penalty.

On Sparc processors, the kernel is ultimately responsible for saving registers to the stack and restoring them from it. When a function is called, the registers are saved into a hardware circular buffer. When the buffer is about to overflow, the processor traps into the kernel which saves the oldest registers to the userland stack. When functions return, the last set of registers is popped off the ring buffer. If the registers are not in-hardware, the kernel is invoked to restore them from the stack. Please see the below whitepaper for a less diluted account.

StackGhost interfaces with the kernel trap handler that would normally write out registers to the stack and the handler that would read them back in. By XORing a cookie into the return-address saved in the user stack when it is actually written to the stack, and then XOR it out when the return-address is pulled from the stack, StackGhost can cause attacker corrupted return pointers to behave in a manner the attacker cannot predict. StackGhost can also use several unused bits in the return pointer to detect a smashed return pointer and abort the process.

A more sophisticated mechanism is under development that will keep a seperate per-process but kernel-space stack of the userland return addresses. If the process attempts to return to an address that is not associated with a function's caller, the process will be aborted. Since the return-address stack is in protected kernel-space, an attacker can under no circumstances access the return-address stack. There are still some serious threading and setjmp/longjmp issues to iron out.


Performance: The SPEC95int benchmark suite showed a StackGhost overhead of less than one percent over the geometric mean. Further benchmarks indicate that the deviation was more attributable to noise than StackGhost. One round of benchmarks actually showed a StackGhosted system was a percent faster than an un-StackGhosted machine.

Compatibility Issues: The only issues to date have been the breakage of GDB (the GNU Debugger). Time permitting, we will remedy the problem via the kernel core dump mechanism.

White Papers: Only a draft and its a bit raw in parts.

Mike Frantzen and Mike Shuey. "StackGhost: Hardware Facilitated Stack Protection." 2001. Published in USENIX Security Symposium '01. [ps] [pdf] [html]

Presentation Slides [ps] [pdf]






Copyright (c) 2001 Mike Frantzen, West Lafayette, IN, USA.

---

This was taken from HERE

Study this and share your ideas about this with us here on AO :)

Cheers.

Call me cynical, but not "yet another" attempt to protect against stack-smashing techniques?

Just like libsafe and all the other various ones, it does a bit to prevent "cookbook" exploits, but people can still do it.

Also, by XORing these return pointers, presumably it does nothing against DoS attacks, as a corrupted pointer will still be corrupted, hence cause a crash.

I'm worried I agree with you Slarty. If this technic would work better than all the others attempts to prevent buffer overflows, it would be called a miracle.
It seems to me they have simply move the problem on another part of the system. Implementing anyway another level of complexity in the system, what always tends to increase its instability as we can easily imagine.

KC

Please, don't be so quick to shoot down OpenBSD's buffer overflow protection. Look at the version for this diff: OpenBSD 3.0-CURRENT.

OpenBSD 3.3 released May 1, with ProPolice stack protection. This essentially places 'canaries' in the memory waiting to be overwritten and to kills the offending process(es). 3.3-CURRENT has fully intergrated (still working out a couple bugs, though) W^X protection into the i386 and PPC architectures (it's already fully in 3.3-RELEASE for all other architectures supported, i.e. sparc, sparc64, etc.) that effectively stops all writable parts of memory from being executed, and all executable parts of memory from being overwritten (i.e. buffer overflow --allowing--> code execution). I strongly suggest anyone interested in learning about this read http://www.openbsd.org/33.html and read the [email protected] archives (google for them) as this has been discussed and explained numerous times.

Unlike the MS operating systems so many people are used to, OpenBSD is one of VERY FEW operating systems that gets more stable and secure with every release, without tacking on tons of 'features'. You can download a snapshot right now and it will be <150mb, with X support, or <70mb without x, but including Amazing Things like PF, the legendary packet filter that now supports Round-Robin load balancing and queueing of connections, rather than just packets.

*EVEN IF* someone manages to break this memory protection (which, I might add, NO ONE HAS YET--can you say the same for any Windows security solutions?---something to think about) it provides much bigger of a lock on your box. A lock, as they say, keeps an honest man honest. This sort of lock keeps all but the most extreme hackers out. How many other operating system dev teams take such a proactive security approach? Don't start with the MS 'Trusted Computing' bs now...

Please don't post 'news' on a release that's over a year old and no longer supported.
I'm not trying to attack anyone with this post, so don't take it personally. I'm glad people are finally coming around to bsd :)

--xid

The whole problem of buffer-overflows starts with a developer taking shortcuts. They're easely prevented if you use a different coding practice. Using strncpy() instead of strcpy() to give just one example. Double checking to see you actually get the resources you requested etc. It will make your code bigger but also more stable and less prone to abuse.

What all these stack-smashing, heap-corrupting prevention things do shouldn't be needed when developers learn to write secure code.

Unfortunately non-executable stacks only protect against exploits which actually place code there.

The "return into libc" exploits can defeat nonexec stacks by causing the location jumped to to be in an already trusted executable part of memory.

Also, some programs, notably Java virtual machines, rely on being able to execute code that they've just created (i.e. with the JIT compiler), therefore these nonexec patches typically break them.

SirDice: OpenBSD's code is heavily audited. They use a function of their own, strlcopy, along with strlcat, instead of the weaker strcopy and strcat. These guys know how to write secure code; just check the source. They're not depending on the anti-stack-smashing tools; they're using them as just-in-case preventatives. Many consider the developers of OpenBSD to be some of the best secure-code writers in the world; seriously, just check the code.

slarty: No "return into libc" exploits for OpenBSD's nonexec stack have been discovered yet and granted that it hasn't been around long enough to get really tested, I doubt any will be seen in the near future. Regarding Java: I don't know how, but in -CURRENT the java port seems to be working fine, after a lil tweaking--without breaking thw W^X! Maybe the JIT compiler has been modified to transfer all of the code it's just compiled into the readable section of memory, then executes it.... not sure about the tech. aspect of it but it does work. Thanks for exercising my mind!

Quote:

---

Originally posted here by xid
SirDice: OpenBSD's code is heavily audited. They use a function of their own, strlcopy, along with strlcat, instead of the weaker strcopy and strcat. These guys know how to write secure code; just check the source. They're not depending on the anti-stack-smashing tools; they're using them as just-in-case preventatives. Many consider the developers of OpenBSD to be some of the best secure-code writers in the world; seriously, just check the code.

---

I know what OpenBSD is and does and admire them for the way they audited their source tree. I just wished more developers would take this kind of attitude towards security. It doesn't change my point of view about the whole prevention thing in general. It shouldn't be needed if everyone coded like the OpenBSD team.

Sorry; I thought you were criticizing the team's sloppiness if they *depended* on the stack protection. Maybe if the MS bohemoth coded like the team, they wouldn't be releasing 'buffer overflow' patches every few days... but that day will never come, I think. It's nice to know some people appreciate all the work that goes into obsd!

Quote:

---

Originally posted here by xid
Sorry; I thought you were criticizing the team's sloppiness if they *depended* on the stack protection. Maybe if the MS bohemoth coded like the team, they wouldn't be releasing 'buffer overflow' patches every few days... but that day will never come, I think. It's nice to know some people appreciate all the work that goes into obsd!

---

My point is: If a developer is protected (maybe even depending on it) by some stack-smashing prevention scheme doesn't this tend to make this allready lazy developer even more lazy?

This obviously varies developer to developer. In the case of the OpenBSD team, for example, the developers are using the stack protection technologies to enhance the security. They don't rely on it, nor do they 'get lazy'. Auditing of strcat and strcopy, as well as other insecure functions, is still very much alive in cases where the developers are dedicated--dedicated enough to keep spitting out code that is much more secure even if the stack protection mechanisms fail.

If the dev's rely on the protection, the code is only as strong as the protection. If they use both the more secure calls and stack protections, the code is more secure. Either way, the protection tends to enhance security, and this is the point I was trying to make.

Any more thoughts, anyone?

[edit]
To whoever negged me w/ reason: "hypocrite"
1) you spelled it wrong
2) how am I being hypocritical?
3) at least explain your reasoning or make it publicly known
[/edit]