If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Stack Ghost

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.

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.

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.

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 misc@openbsd.org 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

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.

Oliver's Law:
Experience is something you don't get until just after you need it.

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!

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.

Oliver's Law:
Experience is something you don't get until just after you need it.

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!

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?

Oliver's Law:
Experience is something you don't get until just after you need it.