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

31–40 of 67 posts

Re: Linux RNG flaws

#31

Post by jakeogh »

amelius wrote: post #30
jakeogh wrote: post #25

Earlier quoted context omitted.

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.

Or how about it blocks, and then if the user starts rambling on the keyboard, it collects entropy?

Right, that would be fine. I think. The point is it's gotta break in a way that requires attention. In the IOT setting often no user input easily available. The OS should not lie to the apps when it hands them numbers that are supposed to be crypto random.

Re: Linux RNG flaws

#32

Post by IcePic »

tinus_hn wrote: post #13
edflsafoiewq wrote: post #9

Earlier quoted context omitted.

What kind of applications need cryptographic randomness during early boot?

The classic application is generating the ssh server keys. I don’t know if that solely uses the system RNG though.

I wonder what sshd could turn to in order to get entropy if the system doesn't think it has enough?

Re: Linux RNG flaws

#33

Post by tinus_hn »

AstralStorm wrote: post #20
tinus_hn wrote: post #13

Earlier quoted context omitted.

The classic application is generating the ssh server keys. I don’t know if that solely uses the system RNG though.

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.

Re: Linux RNG flaws

#34

Post by tinus_hn »

IcePic wrote: post #32
tinus_hn wrote: post #13

Earlier quoted context omitted.

The classic application is generating the ssh server keys. I don’t know if that solely uses the system RNG though.

I wonder what sshd could turn to in order to get entropy if the system doesn't think it has enough?

If it can tell if the system doesn’t have enough, it can just wait for a while longer.

Re: Linux RNG flaws

#35

Post by londons_explore »

cryptonector wrote: post #3
snissn wrote: post #2

Tldr?

From TFA: > == Discarded early randomness, including device randomness == > == RNG is treated as cryptographically safe too early == > == Interaction between kernel and entropy-persisting userspace is broken == > == No entropy is fed into NUMA CRNGs between rand_initialize() initcall and crng_init==2 == > == initcall can propagate entropy into primary and NUMA CRNGs while crng_init==1 == and > == Impact == > I have s…

"105 bits" isn't too shabby.

I'd only start to worry when it gets to say 70 bits or less. That's the kind of size a state actor could precompute ssh host keys for each of the initial random number states in a common distro for example.

If a state actor could compute ssh keys in 50 milliseconds on custom hardware, and they had 100,000 machines generating those keys, they could generate enough keys to have a 1 in 1 million chance for 70 bits of entropy after 20 years.

Re: Linux RNG flaws

#36

Post by dullgiulio »

zaarn wrote: post #23
amelius wrote: post #18

Earlier quoted context omitted.

Why doesn't the device simply block until it has collected sufficient randomness?

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

Re: Linux RNG flaws

#37

Post by jlgaddis »

On RHEL 7 (and derivatives), by default, SSH keys are generated on first boot and with entropy acquired from /dev/urandom.

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?

---

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

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.

Re: Linux RNG flaws

#39

Post by tytso »

hsivonen wrote: post #10
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.…

What reasons are there not to implement the OpenBSD model where the bootloader passes the kernel a seed that the kernel generated previously?

The reason why this is hard is because Linux is supported on a great number of architectures, and some architectures have more than one boot loader that is used. The approach of letting the bootloader pass seed entropy is the right answer in general, I agree, but unlike OpenBSD we can't assume that it will always be present. (OpenBSD only supports a limited number of architectures, and a single bootloader.) Hence, no matter what, we have to have fallback mechanisms for dealing with the case where we have a bootloader which doesn't pass a seed to the kernel.

The other issue is that I don't get paid to work on the random driver in Linux. I've been looking for volunteers to work with the grub, syslinux, efistub, not to mention all of the various signed bootloaders used by different Android devices, but because we had a fallback mechanism there is less motivation for people to want to work on this.

This would actually be a great intern project or GSOC project, but this have been so hectic this year, personally and professionally, I didn't have the time to commit to hosting an intern or GSOC student this summer. :-(

Re: Linux RNG flaws

#40

Post by tytso »

acd wrote: post #28
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.…

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

Cloud 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.
Post reply on HN