mailing list archives
Re: Buffer overflow prevention
From: Peter Busser <peter () trusteddebian org>
Date: Fri, 15 Aug 2003 11:10:31 +0200
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
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.
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
The Adamantix Project
Taking trustworthy software out of the labs, and into the real world
- Re: Buffer overflow prevention, (continued)