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/
This archive was generated by hypermail 2b30 : Fri Aug 15 2003 - 10:05:16 PDT