The flaws only applied for keys generated during early boot. Jann and I looked, but we didn't find a way that this could be turned into a practical exploit, which is why we considered, but decided against, doing any kind of coordinated disclosure. The potential weakness applies before you see crng_init=2 message, and in practice on many machines this happens well before a minute --- on my laptop, in under 10 seconds.<p>The main problem with the fix is that there are some userspace applications which assumed they could get cryptographic randomness super-early during system startup, and with a patched kernel, those userspace applications would block --- and in some cases, block the boot altogether. With no activity, there is no entropy to harness, and the boot scripts essentially deadlock waiting for the random pool to be initialized.<p>So for some hardware, and some distributions, we're getting some boot hangs that we now need to try to workaround or fix somehow. In general, the best thing to do is not to rely on cryptographic strength random number generation during early boot. Key generation should be done lazily, and deferred for as long as possible.
On RHEL 7 (and derivatives), by default, SSH keys are generated on first boot and with entropy acquired from /dev/urandom.<p>It is possible, however, to force it sshd-keygen, sshd, et al., to use /dev/random instead (by setting "SSH_USE_STRONG_RNG" in /etc/sysconfig/sshd to a value >= 14). In this case, would keys still potentially be at risk?<p>---<p>For a while now, I've been generating my SSH host keys at the end of the kickstart installation process (for physical hosts) with SSH_USE_STRONG_RNG=32 (in a "%post" script).<p>Virtual guests (KVM) still generate theirs on first boot, but they have the benefit of access to the host's /dev/random and also get a random seed "injected" into their disk image just before first boot -- although I'm not sure if that helps with this issue.
Just to be sure I understand fully, if I take a small embedded router running OpenWRT, that maybe take ~1min for the urandom pool to be ready.
<a href="https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=3946a5529132c80793a9e5ee665a3cd6b0835310;hp=e408abd7fb8e2a8842726345f393236c53496933" rel="nofollow">https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;...</a>
On the first boot we save 512 bytes from getrandom().
On the second boot we restore the seed (cat seed > /dev/urandom) before almost all the user space starts.
Many daemons (dropbear/openvpn) will read from /dev/urandom before urandom pool is considered ready, but after the seed is restored.<p>With the new patches, are the daemons benefiting from the seed ?
Seeing that `i % len` in <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/char/random.c?id=dc12baacb95f205948f64dc936a47d89ee110117" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...</a> makes me uncomfortable. This is performing a non-constant modulus on every loop iteration, which seems quite excessive even for a slow path. Performing wraparounds using a separate branch would be more efficient.
It's worth noting that FreeBSD also had some RNG troubles quite recently (2017)[0] (talk: [1]). Personally, I don't think they were as severe as this. (But I am biased, I do FreeBSD development.) What I'm trying to say is, getting random right is hard. It's easy to produce something random-looking that isn't good enough.<p>JMG's FreeBSD 2017 RNG talk Tl;dr:<p>1. Boot-time entropy might leak on either UFS or ZFS; might be re-used in a byzantine ZFS environment. (Not addressed, as far as I know.)<p>2. Input entropy data (pre-whitening) had only about 0.18 bits of entropy per byte of input. NIST likes to see 4-6 bits per byte. (Not really an issue due to sufficient input volume.) Partially due to:<p>3. All the fast, high-quality sources of random entropy were accidentally disabled(!). (All the PURE_* ones, including x86 RDRAND.) Fixed in r324394.<p>4. Other low entropy structures were getting mixed in. Probably harmless, but reduces entropy-per-byte measure that NIST cares about. Fixed in r324372.<p>The earlier 2015 FreeBSD RNG issues were probably as severe as this Linux issue[2]:<p>> URGENT: RNG broken for last 4 months<p>> If you are running a current kernel r273872 or later, please upgrade
your kernel to r278907 or later immediately and regenerate keys.<p>> I discovered an issue where the new framework code was not calling
randomdev_init_reader, which means that read_random(9) was not returning
good random data. read_random(9) is used by arc4random(9) which is
the primary method that arc4random(3) is seeded from.<p>> This means most/all keys generated may be predictable and must be
regenerated. This includes, but not limited to, ssh keys and keys
generated by openssl. This is purely a kernel issue, and a simple
kernel upgrade w/ the patch is sufficient to fix the issue.<p>[0]: <a href="https://www.funkthat.com/~jmg/vbsdcon_2017_ddfreebsdrng_slides.pdf" rel="nofollow">https://www.funkthat.com/~jmg/vbsdcon_2017_ddfreebsdrng_slid...</a><p>[1]: <a href="https://www.youtube.com/watch?v=A41cDCE6pTc" rel="nofollow">https://www.youtube.com/watch?v=A41cDCE6pTc</a><p>[2]: <a href="https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054580.html" rel="nofollow">https://lists.freebsd.org/pipermail/freebsd-current/2015-Feb...</a>
man urandom<p>> When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized.<p>I see no bugs here. Just repeating what is written in the man page.
Wasn't there a popular article with the author vehemently supporting the use of /dev/urandom because of it's nonblocking characteristics? I vividly remember it.<p>Also I think it's common knowledge that there's little entropy available during startup but developers have no control over it regardless.<p>I <i>didn't</i> know it was <i>that</i> bad though. That's really bad.