[PATCH] malloc: Fix [BZ #22853] weak randomization on thread arenas.

[Hector Marco]

Hello Adhemerval,

Good to see you are processing this. Please let me share our view about
the issue here:

>
> My main issue about using ASLR entropy is it provides different values
> depending of the underlying architecture and kernel configuration. And
> glibc still support some architecture that do not support ASLR at all.

We don't see the problem here. Can you please elaborate a little bit
more what's wrong? To our understanding (and what our patch does) if an
architecture does not support ASLR then no randomization is applied.

> And, as you pointed out, even for some ASLR enabled architectures the
> entropy most kernels provides is low.

The kernel entropy is not low. Actually the aliment is the one
destroying the entropy but the entropy provided by the kernel is a high
quality entropy one.

>
> That's why I would prefer a platform-neutral solution.  As I pointed
> out some bits from AT_RANDOM are still unused, and I don't see why
> we can't use it here.
>

We don't thing so. The kernel provides 16 random bytes via AT_RANDOM and
on 64-bit architectures those bytes are already used by the stack
smashing protector and the pointer guard glibc. Please look at the
sysdeps/generic/dl-osinfo.h file.

Therefore, we will be introducing a correlation (weakness) and attackers
could use a partial info leak to bypass the canary (among other attacks).

A different history would be to change how we are using the entropy from
AT_RANDOM. As suggested by kernel developers, we could probably use it
to feed a CSPRNG (note that we cannot claim that arc4random is an
entropy source but an entropy collector or intermediary).

We didn't go for this because the obvious overhead introduced. Right now
our solution has zero overhead and it provides good entropy (a
info leak cannot be used to leak anything else than what it is already
known, the mmap area).


>>
>> Also, remember that if the randomization of the arenas are
independent of the rest of the memory layout, then there must be a
mechanism to disable it. It is necessary for debugging.
>
> For such scenario we might disable randomization with a tunable.
>

Yes, we can but as you said, there are architectures that does not
support ASLR and it sounds odd to disable part of the ASLR on
architectures that have no ASLR at all.