[PATCH] Use arc4random() to permutate talloc_magic number

Timur I. Bakeyev timur at freebsd.org
Fri Feb 16 02:32:55 UTC 2018


Hi, Andrew!

On 14 February 2018 at 04:51, Andrew Bartlett <abartlet at samba.org> wrote:

> On Wed, 2018-02-14 at 03:59 +0100, Timur I. Bakeyev via samba-technical
> wrote:
> > Hi!
> >
> > I've noticed that talloc testsuite fails on FreeBSD cause talloc_magic is
> > always a predictable number, derived from the function address of the
> > loaded library, which is unfortunately always the same(contrary to
> OpenBSD,
> > for example). The existing talloc code uses Linux/glibc specific calls to
> > obtaining random bytes to permutate talloc_magic. *BSD has their own set
> of
> > arc4*  functions that can provide cryptographically applicable PRNG.
> >
> > So, this small patch adds support for the usage of arc4random() to obtain
> > random talloc_magic signature per invocation.
>
> The problem I have with this being the default is that unlike on *BSD
> arc4random on in libbsd relies on the recent getentropy() stuff or goes
> back to /dev/urandom.
>
> Now, you don't link against libbsd intentionally, but I can see that
> happening.
>
> I chose the getauxval() because we don't want the library constructor
> for talloc looking to open files.
>
> Sorry,
>

I understand your concerns about possibility of some misuse of arc4random()
on a
Linux platform, although not very likely to happen. But what shall FreeBSD
and other
*BSD users do in that case? Just stay without any protection from pool
hijacking?

I think it's not very fair in regards to *BSD community. Can we find some
solution that
would make everyone happy?

Is your main concern regarding this patch that it makes arc4random()
preferable choice
over getauxval()? That can be fixed with some code re-arrangement and macro
magic.

With regards,
Timur Bakeyev.


More information about the samba-technical mailing list