On Wed, Apr 19, 2000 at 03:24:22AM -0400, Albert D. Cahalan wrote:
> Well then, there are two easy ways to stop this attack.
I wouldn't call them easy. I would call them a royal pain to
impliment.
> First of all, you can mess up the address of the string by
> randomizing the initial stack pointer. One might be willing
> to use 10 to 16 bits of randomness. If a failed attack kills
> the daemon, it is not likely the attack will succeed.
Now this one actually has some prospects. Most exploits
require some knowledge of at least a few addresses on the stack.
16 bits of randomness would walk your stack over 1/4 of a meg (stacks
are aligned on at least a 4 byte boundry remember). That's a lot
of space. You could still do an effective job with only 6 bits, though.
Random guessing 1 chance out of 64 and you only get one shot at it...
That's got some possiblities and would only consume 256 bytes of stack
per process. You could scale that up if you thought it necessary or
even make it run time configurable.
You might get even trickier and do it on a page boundry in
the address space. That way you wouldn't even be sacrificing any
real memory. Just vary the address of the page that the stack
starts on...
Hmmmm.... I like that idea...
I'll have to give that one some serious thought and see if I've
got any exploits in my libraries which do not depend on knowing the
absolute location in memory. I don't know of any off the top of my head.
> Second of all, you can mess up the address of the system call
> by randomizing where the library is loaded. Same as above,
> you might use 10 to 16 bits of randomness. The attacker gets
> only one chance if the daemon crashes.
Moving the library around is likely to play hell with memory
mapped files and text segments in dynamic linked programs and would
be darn near impossible in static linked programs. I don't really
think you want to go down that road.
There's another answer as well. That's Crispin Cowan's (I
think I spelled his name right) Stack Guard. It puts guard bands
around the stack frames and checks them on exit. He's made some
improvements in it over the years to guard against constant value
attacks (he randomizes the guard bands) and to improve the performance
(it use to consume 10-20 percent of the program performance) but it's
really REALLY tough to smash those stacks at all.
If you can afford the performance hit, you don't care if the stack
is executable or not. The program blows up in a controlled, safe, maner
AND you get alerted to a buffer overrun. I think that they had released
and entire stack guarded distribution based on RedHat, but I think it was
still 5.x. They may have updated it. I haven't looked at it in a long
time and it's been around as long as Solar Designers non-executable stack
patchs have been as well.
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:15 EST