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

1–10 of 67 posts

Re: Linux RNG flaws

#3

Post by cryptonector »

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 spent a few days attempting to figure out how bad these issues are.
    > I believe that on an Intel Grass Canyon system, with RDRAND disabled,
    > ASLR disabled, fast boot enabled, no connected devices, with boot on power,
    > some frequency scaling options disabled, and the fan set to maximum,
    > it should be possible to express the entropy in the used RDTSC samples in around
    > 105 bits or less. (I'm not sure which parts of this configuration actually
    > influence the amount of entropy; but ASLR certainly does influence it, since the
    > one interrupt sample that is fed into the RNG before the RNG initialization
    > contains an instruction pointer.)

Re: Linux RNG flaws

#5

Post by ethbro »

snissn wrote: post #2

Tldr?

Early system, post-boot randomness is hard. Linux wasn't handling it ideally. Consequently, things which relied on a cryptographically safe RNG were likely executing before that could be guaranteed.

Sequencing was modified to better align expectations with actual system operation.

Re: Linux RNG flaws

#6

Post by ploxiln »

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…

Due to some unfortunate complications of somewhat recent changes:

> The worst part of this (one device entropy sample being enough to move to crng_init==1) was AFAICS introduced in commit ee7998c50c26 ("random: do not ignore early device randomness"), first in v4.14.

confirmed by the fix for that bit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Re: Linux RNG flaws

#7

Post by loeg »

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.

JMG's FreeBSD 2017 RNG talk Tl;dr:

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

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:

3. All the fast, high-quality sources of random entropy were accidentally disabled(!). (All the PURE_* ones, including x86 RDRAND.) Fixed in r324394.

4. Other low entropy structures were getting mixed in. Probably harmless, but reduces entropy-per-byte measure that NIST cares about. Fixed in r324372.

The earlier 2015 FreeBSD RNG issues were probably as severe as this Linux issue[2]:

> URGENT: RNG broken for last 4 months

> If you are running a current kernel r273872 or later, please upgrade your kernel to r278907 or later immediately and regenerate keys.

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

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

[0]: https://www.funkthat.com/~jmg/vbsdcon_2017_ddfreebsdrng_slid...

[1]: https://www.youtube.com/watch?v=A41cDCE6pTc

[2]: https://lists.freebsd.org/pipermail/freebsd-current/2015-Feb...

Re: Linux RNG flaws

#8

Post by tytso »

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.

Re: Linux RNG flaws

#9

Post by edflsafoiewq »

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 kind of applications need cryptographic randomness during early boot?

Re: Linux RNG flaws

#10

Post by hsivonen »

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