|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: stackguard-like embedded protection
From: Crispin Cowan (crispin
WIREX.COM)Date: Fri Sep 08 2000 - 02:22:06 CDT
- Next message: James Robbins: "Re: ICMP and BlackICE (fwd)"
- Previous message: Pluto: "Re: SSL & IDS"
- In reply to: antirez: "stackguard-like embedded protection"
- Next in thread: antirez: "Re: stackguard-like embedded protection"
- Reply: Crispin Cowan: "Re: stackguard-like embedded protection"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
antirez wrote:
> This is trivial, maybe also world-wide known, anyway:
> a stackguard-like protection can be implemented
> in a quite portable way:
I finally got around to carefully reading this code (I apologize for the
delay).
> int __save_rand;
a static variable, hence ...
> int get_rand()
> {
> __save_rand = RANDNUM; /* WARNING: not reentrant */
> return RANDNUM; /* /dev/urandom can be ok */
> }
... as you say, not reentrant, and therefore not recursive. Furthermore, you
can't use "safe_enter" and "safe_leave" in more than one function at a time.
This is not just a detail; it is a critical issue in designing a stack smashing
defense. To do integrity checking on the stack, you need to insert canaries
that have these properties:
* you can decide whether your integrity marks are still intact when you
return
* you can do so through a sequence of recursive calls
* you are not depending on the stack itself to detect these factors (because
the attacker can corrupt the stack)
There are three obvious solutions to this:
* totally static canary: we used the "terminator" hack because we
conjecture that it is hard for buffer overflows to generate terminator
symbols
* load-time static canaries: we bind values from /dev/random to functions
at load time
* use an alternate stack: StackShield uses this approach. We also thought
of that, but discarded it because the first two solutions seemed easier
than the alternate stack, and we could not find any way in which the
alternate stack was safer
So the provided code is an interesting experiment, but is not practical until
it chooses one of these solutions (or invents a new one) that addresses the
recursive problem in a way that is robust against stack smashing.
Crispin
-- Crispin Cowan, Ph.D. Chief Research Scientist, WireX Communications, Inc. http://wirex.com Free Hardened Linux Distribution: http://immunix.org Olympics: The Corruption Games
- Next message: James Robbins: "Re: ICMP and BlackICE (fwd)"
- Previous message: Pluto: "Re: SSL & IDS"
- In reply to: antirez: "stackguard-like embedded protection"
- Next in thread: antirez: "Re: stackguard-like embedded protection"
- Reply: Crispin Cowan: "Re: stackguard-like embedded protection"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]