11 ms·
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, wh
by tytso 8y ago
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.
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.
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.
- edflsafoiewq 8y agoWhat kind of applications need cryptographic randomness during early boot?
- tinus_hn 8y agoThe classic application is generating the ssh server keys. I don’t know if that solely uses the system RNG though.
- AstralStorm 8y agoPretty silly. If you can network, you have access to at least 3 decent sources of entropy. (Network traffic, hardware clock randomness and network device clock. Potentially power supply monitoring and bus clocks. And finally thermal sources.) And then you can always bake in the key into flash. The problem here is that you would have to probe RNG stats manually as it returned readiness too early.
- tinus_hn 8y agoYou don’t need network to start the SSH server, it just listens on all interfaces. Also, although it doesn’t matter that much in this case, trusting the network for entropy is not such a great idea because it isn’t trusted.
- AstralStorm 8y agoThat is only relevant if your entropy estimator and mixer is broken and/or you have too few entropy sources. Linux entropy handling is quite well tested. (As opposed to initialization of the RNG.)
- IcePic 8y agoI wonder what sshd could turn to in order to get entropy if the system doesn't think it has enough?
- tinus_hn 8y agoIf it can tell if the system doesn’t have enough, it can just wait for a while longer.
- hsivonen 8y agoWhat reasons are there not to implement the OpenBSD model where the bootloader passes the kernel a seed that the kernel generated previously?
- IcePic 8y agoThere is no reason not to try it, but you would still want to cater for the initial boot when you have no previous entropy to read.
- hsivonen 8y agoCouldn't the installer write the initial seed?
- ddtaylor 8y agoIt's seeds all the way down.
- chopin 8y agoThere's not always an installer, I make heavily use of live images. On other machines of mine, first boot is made from a copied image.
- jlgaddis 8y agoYou may know this but for others who may not: there are tools like virt-sysprep that can (among other things) inject a random seed into disk images. If you clone/generate VMs from one "master" image, running virt-sysprep (or similar) is one of the steps you should do right before launching a new instance (inject a new random seed, wipe out any SSH host keys, etc.) Even DigitalOcean missed doing this step a while back.
- JdeBP 8y agoI was about to mention the same thing. A pass to make an image unique before bootstrapping it is, or should be, a well-known thing. Remember the hoo-hah over unique machine SIDs in Windows NT. And there is of course the Freedesktop world's systemd-firstboot for making unique machine IDs in images in D-Bus and systemd.
- zaarn 8y agoI think that problem could be handled by having the RNG return an error until crng_init=2 and introduce a way to check the state of the kernel RNG. Applications can then check if the kernel is ready to do RNG and if not, handle the delay themselves. But I guess that would break some applications so there might be another way (extra device for early boot randomness? ioctl?)
- amelius 8y agoWhy doesn't the device simply block until it has collected sufficient randomness?
- zaarn 8y ago/dev/random kinda does but a lot of applications also rely on /dev/urandom which doesn't, which is why it's a problem to some extend. Atleast from what I know.
- dullgiulio 8y agoI don't understand why it's not possible to make /dev/random block until there is enough entropy in the pool for the seed, and never block afterwards when it can securely do key-stretching. After seeding, there is no point in blocking on a lack of entropy, which is why it is recommended to use /dev/urandom in the first place.
- therein 8y ago> So for some hardware, and some distributions, we're getting some boot hangs that we now need to try to workaround or fix somehow. I recently updated to a 4.x series kernel and had this issue during boot. I had to interact with the VM to get it to unblock and boot.
- acd 8y agoIn cloud during new machine install ssh host keys are generated during boot time well under a minute. Say that the virtual host machine that hosts the virtual machines writes the disk image to local disk, the disk image is then in cache memory on the virtual host, the virtual machine boots from what is essentially a file in RAM cache or a fast SSD.
- tytso 8y agoCloud hosting is actually the easiest case because you have to trust the host environment anyway. (If you can't, you're sunk.) So we just can trust the use of virtio-rng. Setting this up for qemu is pretty simple.
- Sir_Cmpwn 8y agoSome distros dump the entropy pool to disk during shutdown and feed it back in during early boot. Would this mitigate the issue?