Re: [gentoo-hardened] ssp random bytes solution

[Ned Ludd]

- len = read(fd, (char *) &__guard, sizeof(__guard));
+ len = read(i, (char *) &__guard, sizeof(__guard));

On Tue, 2004-04-20 at 00:02, Ned Ludd wrote:
> On Mon, 2004-04-19 at 22:29, Robert Connolly wrote:
> > On April 19, 2004 09:16 pm, Ned Ludd wrote:
> > > On Mon, 2004-04-19 at 17:55, Robert Connolly wrote:
> > >>...
> > > Could you test the following attachment (guard-test) a few times and
> > > post the results?  Mainly I'd like to verify that your __guard is infact
> > > working as expected. (It should SEGFAULT or SIGABRT)
> >
> > ./guard-test
> > main    =       0x800009d4;
> > __guard =       0x4012aba0;
> > __stack_smash_handler   =       0x4002de50;
> > __guard =       0x4012aba0;
> > __stack_smash_handler   =       0x4002de50;
> > guard-test: stack smashing attack in function mainAborted
>
> And how about a second run... __guard is at a different location?
>
> >
> > > I took a quick look at the (glibc) code and it appears as if you drooped
> > > support completely for /dec/urandom I'm not sure if that's a good idea
> > > because if a user decides not to use frandom then she will end up with
> > > the default canary only which would weaken the entire model..
> >
> > That doable. But sysctl random_uuid could also be used as a second fallback. /
>
> kernel.random.uuid can only be read by uid 0
> Actually I'm not 100% sure on this because I've had my /proc/sys
> restricted for so long thanks to grsecurity..
>
>
> > dev/{e,f}random third, urandom fourth... I just used sysctl erandom so not to
> > make it too complicated for now.
>
> What would be the point of even looking for /dev/{e,f} if the sysctl()
> failed?  Either we are using frandom or not. Right?
>
> I would think the logic would work something like this untested
> attachment.
>
> > > Also can this be enabled in the kernel as non LKM?
> > > As handy as modules are they are a security risk and should be avoided
> > > at all costs.
> >
> > As in built in? yes. The sysctl support will not work as a module.
> >
> >
> > --
> > gentoo-hardened@g.o mailing list
-- 
Ned Ludd <solar@g.o>
Gentoo Linux Developer