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.
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.
17 comments on “FreeBSD and the YARNBUG – more trouble at the Random Number Mill”
How does this issue affect online password generators, whether freestanding or as part of a password manager program?
This issue doesn’t affec online password generator Unless that your server use FreeBSD such vulnerable version
Note that CURRENT is the alpha/development version and is not intended for production or stable use.
Just as well! The bug was there for four months before it was spotted.
PRNG bugs can be like that: how can you tell that de445140a768 was random while a7fdacbe132b was not 🙂
No disagreement that the issue is serious (bug and process both) , but it is factually incorrect to say “the latest release of FREEBSD” was affected.
You’re grasping at semantic straws, but to keep you happy I have changed the one place where I talked about -CURRENT as a release to call it a “version.”
You didn’t give me credit for explicitly saying: “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.”
Not sure how I could really have been clearer, and even though FreeBSD doesn’t officially use the term “release” except for production versions, you have to admit that a downloadable version called “-CURRENT” has to be considered released in fact, if not in terminology…
It’s not merely a matter of semantics but is at the core of the issue. If we were talking about a bug of this nature in Microsoft Windows and you wrote “the latest release of Windows,” nobody would assume you actually meant a beta that happened to be on a DVD.
If you look at FreeBSD’s releases page (https://www.freebsd.org/releases/) there is no mention of -CURRENT, and on the snapshots page (where pre-built -CURRENT images are found) it clearly states: The snapshots are primarily for testing purposes and not fully tested compared to the releases. They may include experimental or degraded features that can corrupt your existing system. It also says “these are not releases.”
I suspect casual readers would still interpret “the latest version of FreeBSD” to mean the FreeBSD 10.1 release. Something like “the latest development snapshot” seems both clear and correct. I’m not asking that you change the text – these comments and discussion on twitter and other forums sufficiently explain the issue.
Let me say though that it is precisely because the rest of the article is so spot-on that the error seemed out of place.
FWIW the original anonymous post above is not mine, but the point remains valid.
You are trying to create news where there is none. CURRENT is the location where development happens. Here are the pertinent quotes from the documentation of the FreeBSD project, that you are encouraged to read in-depth before publishing FUD such as you have done above.
FreeBSD-CURRENT is the very latest source code for FreeBSD and includes works in progress, experimental changes, and transitional mechanisms that might or might not be present in the next official release. While many FreeBSD developers compile the FreeBSD-CURRENT source code daily, there are short periods of time when the source may not be buildable. These problems are resolved as quickly as possible, but whether or not FreeBSD-CURRENT brings disaster or new functionality can be a matter of when the source code was synced.
FreeBSD-CURRENT is made available for three primary interest groups:
Members of the FreeBSD community who are actively working on some part of the source tree.
Members of the FreeBSD community who are active testers. They are willing to spend time solving problems, making topical suggestions on changes and the general direction of FreeBSD, and submitting patches.
Users who wish to keep an eye on things, use the current source for reference purposes, or make the occasional comment or code contribution.
FreeBSD-CURRENT should not be considered a fast-track to getting new features before the next release as pre-release features are not yet fully tested and most likely contain bugs. It is not a quick way of getting bug fixes as any given commit is just as likely to introduce new bugs as to fix existing ones. FreeBSD-CURRENT is not in any way “officially supported”.
My goodness, you’d swear you hadn’t read my article at all. WE’RE TAKING THE OPPORTUNITY TO REMIND PEOPLE WHY RANDOMNESS REALLY MATTERS, AND THAT EVEN EXPERTS CAN GET IT WRONG.
We’re not taking a pop at your beloved FreeBSD, or trying to suggest that this is a problem likely to be seen on production servers, which is why we expressly said just that very thing in the article.
Indeed, we described -CURRENT as a “pre-release,” just like FreeBSD itself does.
Interestingly, and amusingly, however, it seems that we fall right into the category of people who *are* suited to the -CURRENT version, namely “users who want to keep an eye on things” 🙂
Fourmi labs in Switzerland generates not a PRNG, but one based on the radioactive decay of Cs 137 into Barium. Hence no algorithm that tends to have patterns.
What kind of hardware is need to meause the radioactive decays?
YARNBUG is a great name!
Well, if a random generator tells any kind of story, it’s a bug 🙂
“with just 31 bits’ worth of randomness: the value of the current process ID.”
Minor correction, but that should probably read “15 bits” instead of 31. The article you linked to seems to confirm my suspicion since it says “there are only 32,767 possible outcomes for a given architecture, key size, and key type”.
Don’t know how that happened. I did indeed mean 15 bits. Fixed, thanks.
or you could go to random.org?
If you’re that hung up on randomness for security, you still need to generate a sufficiently random number to ensure that your web session(s) aren’t easily pilfered as well.