* Jeremie Le Hen <jere...@le-hen.org> wrote: > On Fri, Jul 24, 2009 at 01:56:49PM +0200, Ed Schouten wrote: > > * Jeremie Le Hen <jere...@le-hen.org> wrote: > > > On Fri, Jul 24, 2009 at 11:18:42AM +0300, Kostik Belousov wrote: > > > > On Fri, Jul 24, 2009 at 09:34:51AM +0200, Jeremie Le Hen wrote: > > > > > Hi Ed, > > > > > > > > > > Sorry for the late reply. > > > > > > > > > > On Sat, May 09, 2009 at 02:13:13PM +0200, Ed Schouten wrote: > > > > > > We probably could. I think I discussed this with Robert Watson some > > > > > > time > > > > > > ago and we could use things like ELF hints. But still, that doesn't > > > > > > prevent us from reaching this limitation later on. > > > > > > > > > > Can you elaborate a little? Are you talking about elf-hints.h? > > > > > I don't see where we can get randomness from it. > > > > > > > > The thing is called ELF auxillary information vector. It is used to > > > > supply some useful information for interpreter from the kernel, > > > > see include/machine/elf.h for AT_* entries. > > > > > > Ah ok, so the idea is to generate a new hint, for instance AT_RANDOM, > > > generated at link time, that will be used to fill the canary at exec(2) > > > time? > > > > Very short answer: yes! > > Ok thanks. But this would make stack protection useless for local > attacks on suid binaries that are world-readable since the attacker > could read the ELF aux vector and compute the canary.
Wait wait wait. It seems you were only partially right (and Kostik corrected you): We could add AT_RANDOM, but this value will be filled in by the kernel when starting the process. This means the random value is not stored in the binary. -- Ed Schouten <e...@80386.nl> WWW: http://80386.nl/
pgpkPBdmMkXBL.pgp
Description: PGP signature
