OpenBSD Journal

StackGhost enabled by default

Contributed by dhartmei on from the foil-stack-smashers-for-fun-and-profit dept.

StackGhost, a transparent stack protection feature (similar to ProPolice, which is already enabled by default on all OpenBSD architectures) for OpenBSD/sparc was invented and implemented on OpenBSD in 2001 by Mike Frantzen and Mike Shuey. Recent work on gdb by Mark Kettenis now allows the feature to be enabled by default.

StackGhost uses a unique hardware feature of the Sun sparc architecture (that being: deferred on-stack in-frame register window spill/fill) to detect modifications of return pointers (a common way for exploits to hijack execution paths) transparently, automatically protecting all applications without requiring binary or source modifications. The performance impact is negligible (less than one percent), but resulting gdb (the GNU debugger) issues were only recently resolved, allowing enabling the feature now.

The same techniques might in the future by applied to OpenBSD/sparc64.

(Comments are closed)

Comments

  1. By Anonymous Coward (213.118.165.230) on

    What advantage does this give over ProPolice, if they're both doing more or less the same thing.

    Or is it just that exploits uncaught by one mechanism may be caught by the other?

    Comments

    1. By djm (203.217.28.239) on

      This is kernel-side, so it works for binaries not compiled with propolice.

      Comments

      1. By Anonymous Coward (213.118.165.230) on

        Is there any chance this will break certain (badly coded) applications?

        Or is gdb just a special case (I can imagine a debugger needs to do quite some funny stuff with the registers and such)?

        Comments

        1. By Anthony (68.145.111.152) on

          The prevailing attitude in OpenBSD circles seems to be "if this breaks it, it deserves to be broken", where "this" is defined as stuff like random order of library loading, ProPolice, etc.

          Comments

          1. By krh (207.75.182.30) on

            That's irrelevant to the previous poster's question. (Besides which, most of that stuff does deserve to break.)

            The above-linked copy of Mike Frantzen and Mike Shuey's Usenix presentation includes this comment:

            "Userland debuggers are currently broken by the XOR cookies. They will not be able to backtrace since the in-core return pointers are obviously distorted. The in-kernel core dump mechanism may be able to walk the stack and cleanse each activation record in the program. Further research must be done. Threaded programs would present an additional beast for reasons outlined above by the kernel return stack.

            Debugging via Ptrace() will also present problems for the parent processes since the in-core program counter will have been modified by StackGhost."

            This makes it sound like most programs should be unaffected. The only exception that comes to mind is GCC's much-hated trampolines--but I don't think much real-world code actually uses nested functions, so there shouldn't be any problems. (Yes, I know we've had a discussion about whether nested functions are "real-world". Let's not start it again.)

    2. By tedu (128.12.75.69) on

      stackghost was developed first, but couldn't be enabled without debugger support. it's also faster, but only protects against certain stack overflows. propolice does a more through job of protecting things like function pointers.

      Comments

      1. By PaX Team (81.182.76.250) on

        ssp (then propolice) was announced in september 2000, whereas stackghost was presented at usenix security in august 2001 (and committed to cvs around february 2002).

        Comments

        1. By tedu (128.12.75.69) on

          my bad. would have helped if i checked the references in stackghost's paper.

    3. By Anonymous Coward (195.217.242.33) on

      It is harware facilitated

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]