Date:   Sun, 29 Apr 2018 18:05:19 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Sultan Alsawaf <sultanxda@...il.com>
Cc:     Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
        Jann Horn <jannh@...gle.com>
Subject: Re: Linux messages full of `random: get_random_u32 called from`

On Sun, Apr 29, 2018 at 01:20:33PM -0700, Sultan Alsawaf wrote:
> On Sun, Apr 29, 2018 at 08:41:01PM +0200, Pavel Machek wrote:
> > Umm. No. https://www.youtube.com/watch?v=xneBjc8z0DE
> 
> Okay, but /dev/urandom isn't a solution to this problem because it isn't usable
> until crng init is complete, so it suffers from the same init lag as
> /dev/random.

It's more accurate to say that using /dev/urandom is no worse than
before (from a few years ago).  There are, alas, plenty of
distributions and user space application programmers that basically
got lazy using /dev/urandom, and assumed that there would be plenty of
entropy during early system startup.

When they switched over the getrandom(2), the most egregious examples
of this caused pain (and they got fixed), but due to a bug in
drivers/char/random.c, if getrandom(2) was called after the entropy
pool was "half initialized", it would not block, but proceed.

Is that exploitable?  Well, Jann and I didn't find an _obvious_ way to
exploit the short coming, which is this wasn't treated like an
emergency situation ala the embarassing situation we had five years
ago[1].

[1] https://factorable.net/paper.html

However, it was enough to make us be uncomfortable, which is why I
pushed the changes that I did.  At least on the devices we had at
hand, using the distributions that we typically use, the impact seemed
minimal.  Unfortuantely, there is no way to know for sure without
rolling out change and seeing who screams.  In the ideal world,
software would not require cryptographic randomness immediately after
boot, before the user logs in.  And ***really***, as in [1], softwaret
should not be generating long-term public keys that are essential to
the security of the box a few seconds immediately after the device is
first unboxed and plugged in.i

What would be useful is if people gave reports that listed exactly
what laptop and distributions they are using.  Just "a high spec x86
laptop" isn't terribly useful, because *my* brand-new Dell XPS 13
running Debian testing is working just fine.  The year, model, make,
and CPU type plus what distribution (and distro version number) you
are running is useful, so I can assess how wide spread the unhappiness
is going to be, and what mitigation steps make sense.


What mitigations steps can be taken?

If you believe in security-through-complexity (the cache architecture
of x86 is *sooooo* complicated no one can understand it, so
Jitterentropy / Haveged *must* be secure), or security-through-secrecy
(the cache architecture of x86 is only avilable to internal architects
inside Intel, so Jitterentropy / Haveged *must* be secure, never mind
that the Intel CPU architects who were asked about it were "nervous"),
then wiring up CONFIG_JITTERENTROPY or using haveged might be one
approach.

If you believe that Intel hasn't backdoored RDRAND, then installing
rng-tools and running rngd with --enable-drng will enable RDRAND.
That seems to be popular with various defense contractors, perhaps on
the assumption that if it _was_ backdoored (no one knows for sure), it
was probably with the connivance or request of the US government, who
doesn't need to worry about spying on itself.

Or you can use some kind of open hardware design RNG, such as
ChoasKey[2] from Altus Metrum.  But that requires using specially
ordered hardware plugged into a USB slot, and it's probably not a mass
solution.

[2] https://altusmetrum.org/ChaosKey/


Personally, I prefer fixing the software to simply not require
cryptographic grade entropy before the user has logged in.  Because
it's better than the alternatives.

					- Ted

Powered by blists - more mailing lists