Message-ID: <20030815091031.GC19569@trusteddebian.org>
Date: Fri, 15 Aug 2003 11:10:31 +0200
From: Peter Busser <peter@...steddebian.org>
To: bugtraq@...urityfocus.com
Subject: Re: Buffer overflow prevention


Hi!

> On August 14, 2003 06:44 am, Mariusz Woloszyn wrote:
> > On Wed, 13 Aug 2003, Patrick Dolan wrote:
> > > There is a flag for the Gnu C/C++ compilers, -fstack-protector, that will
> > > implement ProPolice stack protection.  It should prevent stack smashing
> > > techniques.
> > ProPolice (http://www.research.ibm.com/trl/projects/security/ssp/) is a
> > great tool ...
> GRsecurity is a kernel patch wich allows such things as  random memallc bases
> and random tcp stacks, as well as a non-executeable stack if you can manage
> this (not to mention a utility to change the PAX flags for indidual binarys
> that may need executable stack). This would work much better because it dosnt
> need to be compiled into anything but the kernel.

The patch you are talking about is called PaX (http://pageexec.virtualave.net).
Gr-security uses PaX and other patches.

To make maximum use of PaX randomisation, you would have to recompile/relink
all executables. That is what we have done for Adamantix. Other distributions,
like Gentoo Hardened recently started doing this also.

> If you turn on GRsecurty's randomizations for memory addresses and tcp stacks
> (wich I have tested, you can do this safely without breaking any software).
> If you do this, then a attacker trying to overflow a return address has a 1
> in 2^32 chance of the exploit actually overflowing the address. You can do
> this and not have any impact on speed, and all of your software is protected
> with this level without having to recompile with a gcc flag.

No, the chance is much bigger than that. It is obviously not possible to do
full 32 bit randomisation in a 32 bit address space. I wrote a test suite that
will measure the number of bits of the various randomisations. However, the
PaX randomisation is larger than you will find in OpenBSD.

ET_EXEC randomisation has an impact on the speed, that is why for Adamantix I
chose to recompile/relink all binaries.

Randomisation of stack/heap/executable/mmaps is a form of obfuscation, noone
should rely on randomisation alone for improving the security of a system.

> Also, you can use chpax, and turn on a non-executable stack, and with a small
> amount of voodoo (in tracking down the binarys and .so's that need the stack,
> wich typically is only a single binary or .so file, wich you can find with
> ptrace, strace, or ltrace) you can have all of your stuff run with a
> non-executeable stack, thus making stack smashing impossible.

A non-executable stack patch provides no protection. It is easy to circumvent.
A few years ago there was a discussion about getting the OpenWall non-exec
stack patch into Linus' kernel tree and Linus refused. He showed that it was
easy to circumvent this stuff. That is why PaX provides more than
non-executable stack and randomisation alone.

> Nothing can
> execute off your stack so a malicous person can override all the addresses he
> wants, his code cant run off your stack.

Well, it doesn't have to execute off the stack to be exploitable. Simply
changing the return address can lead to a succesfull exploit. PaX does not
protect against this. And I don't know any kernel patch that does, for that
matter.

Groetjes,
Peter Busser
-- 
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
http://www.adamantix.org/

Powered by blists - more mailing lists