FreeBSD and the YARNBUG – more trouble at the Random Number Mill

The latest vulnerability-with-a-snazzy-name is YARNBUG, and it affects the most recent version of FreeBSD.

Actually, it’s not really called YARNBUG – we just made that up to stand for “Yet Another Random Number Bug.”

We’ve written about problems with randomness many times on Naked Security, because randomness is actually much more important that many people realise.

Loosely put, computer security as good as depends on randomness, and that means something of a paradox: access to a reliable supply of completely unpredictable numbers.

For example, imagine that you encrypt the same document multiple times with the same secret key: you need to “seed” the encryption each time with a random number, or else you’ll keep getting the same encrypted output.

Even though that wouldn’t tell an attacker what’s inside the document, it would needlessly signal that the encrypted files were identical, which isn’t supposed to happen.

Of course, whenever you need a random number, it really must be random.

If it can be guessed or predicted, even a bit, then, well, it simply isn’t random, and you’ll end up with patterns that can be anticipated in data that’s supposed to be entirely empty of meaning until it’s decrypted.

The tricky part of randomess

Clearly, there’s a tricky part to this randomness lark.

How do you test your random number generator?

How do you determine, in an ordered way, that a sequence of numbers is entirely disordered?

How do you ensure that your generator won’t churn out a genuinely random-looking stream of data today, spitting out numbers that pass any and all statistical tests, only to churn out an identically good-looking sequence tomorrow at the same time?

The answer is, “By being very careful indeed!”

But in the latest version of FREEBSD, known as -CURRENT, the kernel programmers weren’t quite careful enough.

They forgot to call a function to ensure that newly-configured random generators were sufficiently “mixed up” enough at the start that they were as good as impossible to predict:

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.

The DRECK disaster

This is a similar sort of blunder to the infamous Debian Random Entropy Catastrophe in the Kernel (DRECK) flaw back in 2008.

In that case, an automatic software analysis tool warned the Debian programmers about some code that looked as though it wasn’t initialised properly, and might therefore produce unreliable, even non-deterministic, results.

So they removed it on the principle that unpredictability and unrepeatability in code is a bad thing.

After all, nobody wants an IsThisUserAuthorised() function that mostly returns false but every now and then says true when it isn’t supposed to.

Of course, irony of ironies, the “unreliable” code was part of the system that seeded the random number generator, and its unreliability was part of its overall reliability.

For a while, Debian random numbers were seeded with just 15 bits’ worth of randomness: the value of the current process ID.

Knock-on effects

The reason we’re writing this story is because problems with randomness, just like problems with virus infection, can cause knock-on effects that are easy to ignore, but can’t be cleaned up automatically.

For example, any cryptographic keys generated while the random number was defective must be considered suspect, on account of containing non-random material.

Fixing the random generator will tighten up the security of any cryptographic keys you generate in future, but it won’t find and eliminate any dangerous predictability from existing keys.

So, as the FreeBSD advisory points out:

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.

The good news is that very few FreeBSD systems in production use will be running the -CURRENT version, which is effectively a pre-release product.

The bad news is that we’re still making YARNBUG mistakes.

Remember: randomness is much too important to be left to chance!

Note. Sophos products that include a FreeBSD kernel do not use the -CURRENT branch, and are therefore unaffected by this bug.

Image of yarn courtesy of Shutterstock.