Bugtraq mailing list archives
Re: Buffer overflow prevention
From: Peter Busser <peter () trusteddebian org>
Date: Fri, 15 Aug 2003 11:10:31 +0200
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/
Current thread:
- Re: Buffer overflow prevention, (continued)
- Re: Buffer overflow prevention Jingmin (Jimmy) Zhou (Aug 13)
- Re: Buffer overflow prevention Craig Pratt (Aug 13)
- Re: Buffer overflow prevention Patrick Dolan (Aug 13)
- Re: Buffer overflow prevention Mariusz Woloszyn (Aug 14)
- Re: Buffer overflow prevention Crispin Cowan (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- RE: Buffer overflow prevention Lance James (Aug 14)
- Re: Buffer overflow prevention Patrick Dolan (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Stephen Clowater (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Solar Designer (Aug 15)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Mariusz Woloszyn (Aug 14)
- Re: Buffer overflow prevention Theo de Raadt (Aug 14)
- Re: Buffer overflow prevention Matt D. Harris (Aug 14)
- Re: Buffer overflow prevention sauron (Aug 14)
- Re: Buffer overflow prevention Timo Sirainen (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Peter Busser (Aug 15)
- Re: Buffer overflow prevention Theo de Raadt (Aug 14)
- Re: Buffer overflow prevention Jedi/Sector One (Aug 14)
- Re: Buffer overflow prevention Miod Vallat (Aug 14)