Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux RNG flaws

bugs.chromium.org

Post reply on HN
Print view View original

41–50 of 67 posts

Re: Linux RNG flaws

#41

Post by tytso »

dullgiulio wrote: post #36
zaarn wrote: post #23

Earlier quoted context omitted.

/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.

I 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.

This is what getrandom(2) does, and using getrandom is the recommended path. However, if you use getrandom(2), and you are in early boot, such as by systemd's journald, and you are using it for some pointless HMAC mechanism with a randomly generated key for no specified security goal and no clearly articulated threat model, then you can end up hanging the boot, leading to the entropy deadlock situation I described.

So getrandom(2) will block until the pool is seeded, and all newly written application should use it, and existing applications should switch to it. But you still need to try to lazily generated random keys, and think very hard about whether you really need to generate cryptographic grade random numbers before the user logs in.

Re: Linux RNG flaws

#42

Post by jlgaddis »

chopin wrote: post #27
hsivonen wrote: post #12

Earlier quoted context omitted.

Couldn't the installer write the initial seed?

There'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.

You 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.

Re: Linux RNG flaws

#43

Post by jlgaddis »

nikic wrote: post #38

Seeing that `i % len` in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... 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.

You should submit a patch.

Re: Linux RNG flaws

#44

Post by sangnoir »

jakeogh wrote: post #25
tankenmate wrote: post #21

Earlier quoted context omitted.

Chicken and egg; it won't properly boot until it has enough entropy, and you don't get enough entropy until it is booted. The proper fix is to change the boot scripts to not assume that the CRNG will be available directly after boot.

It's better to deadlock than to revert to a weak RNG. Deadlocking guarantees the application gets fixed. Reminds me of setting an init system to restart crashed daemons.

> It's better to deadlock than to revert to a weak RNG

..for you. Other people have a different threat model where availability is ranked above RNG strength in the first minute of booting. Making security decisions not based on any sort of threat model considerations is zealotry/cargo-culting, IMO.

Re: Linux RNG flaws

#45

Post by dspillett »

chopin wrote: post #27
hsivonen wrote: post #12

Earlier quoted context omitted.

Couldn't the installer write the initial seed?

There'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.

If you have network access early enough in the install and/or boot processes could you not pluck some random bits from a web service to pump more entropy into the RNG's pool?

For paranoia you could host your own fairly easily instead of using a public one: have a machine that is publicly visible respond with random digits from its own entropy pool, have it use one or more of various methods to keep that pool topped up (local interrupt timings, a hardware RNG, ...), use request hashing with a "secret" key if you are worried about the general public draining your entropy pool or available bandwidth.

And if it can't see the entropy service for any reason (it is booting in an environment where the rest of the network is completely cut off, or perhaps the entropy service is down) then fall back to just doing what-ever is done now.

Re: Linux RNG flaws

#46

Post by masterleep »

tytso wrote: post #41
dullgiulio wrote: post #36

Earlier quoted context omitted.

I 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.

This is what getrandom(2) does, and using getrandom is the recommended path. However, if you use getrandom(2), and you are in early boot, such as by systemd's journald, and you are using it for some pointless HMAC mechanism with a randomly generated key for no specified security goal and no clearly articulated threat model, then you can end up hanging the boot, leading to the entropy deadlock situation I described. S…

Some discussion:

https://lists.freedesktop.org/archives/systemd-devel/2018-Ma...

Re: Linux RNG flaws

#47

Post by Sir_Cmpwn »

tytso wrote: post #8

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.…

Some distros dump the entropy pool to disk during shutdown and feed it back in during early boot. Would this mitigate the issue?

Re: Linux RNG flaws

#48

Post by oconnor663 »

lihes wrote: post #22

man urandom > When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. I see no bugs here. Just repeating what is written in the man page.

If you continue to the next sentence in that man page:

> If this is of concern in your application, use getrandom(2) or /dev/random instead.

These bugs affect getrandom too.

Re: Linux RNG flaws

#49

Post by AstralStorm »

tinus_hn wrote: post #33
AstralStorm wrote: post #20

Earlier quoted context omitted.

Pretty 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.

You 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.

That 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.)

Re: Linux RNG flaws

#50

Post by teovall »

Sir_Cmpwn wrote: post #47
tytso wrote: post #8

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.…

Some distros dump the entropy pool to disk during shutdown and feed it back in during early boot. Would this mitigate the issue?

Part of this flaw was that process wasn't working correctly.
Post reply on HN