FreeBSD-Current Random Number Generator Broken 105
First time accepted submitter bobo the hobo writesThe FreeBSD random number has been discovered to be generating possibly predictable SSH keys and SSL certificates for months. Time to regenerate your keys and certs if using FreeBSD-Current. A message to the freebsd-current mailing list reads in part: "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."
Re:Is FreeBSD dying? (Score:4, Funny)
Netcraft Confirms FreeBSD is dying [facebook.com]
Facebook is too confusing!
Don't you have a Twitter link to share?
Re: (Score:3, Interesting)
I've heard the same things said. However, and I don't say this in jest, that while no security in any OS is perfect, OpenBSD comes the closest due to their audits. Hence, out of the BSDs I do use and endorse, it's OpenBSD.
Some dislike Theo, but he's intensely good at running a tight ship, and since 1999 when I first started using OpenBSD for security-based boxes, I've never had an issue.
Re:But FreeBSD is perfect! (Score:4, Insightful)
since 1999 when I first started using OpenBSD for security-based boxes, I've never had an issue.
That you know about.
Re: (Score:3)
I just checked on openbsd.org, and I loved the FAQ section! ...
4.13 - Common installation problems [openbsd.org]
4.13.1 - My Compaq only recognizes 16M RAM
4.13.2 - My i386 won't boot after install
Re: (Score:2, Insightful)
FreeBSD is the new Linux. Full of religious fan boys who act like it was written by God. This old tired line of "Linux is immune to security issues" is now more commonly used with FreeBSD (by idiots).
You know who started the original BSD? This guy [wikipedia.org] did. He also created the original vi editor, was the creator of the modern day TCP/IP stack, and had a huge hand in the creation of Java. What, praytell, have you done?
Cui bono? (Score:2)
I discovered an issue where the new framework code was not calling randomdev_init_reader
So who was responsible for introducing that change? Let's smoke out the mole.
Re:Cui bono? (Score:4, Interesting)
Newbish question here.. (Score:2)
Re: (Score:3, Informative)
Re:Newbish question here.. (Score:4, Informative)
Both -CURRENT and -STABLE are development branches. [freebsd.org]
-RELEASE is meant for production [freebsd.org] and of course gets supplied with security relevant fixes (then referred to as patchlevels).
But yes, please go on educating people about things you don't know jack about.
Re:Newbish question here.. (Score:5, Informative)
The bug was in the unreleased FreeBSD-11 work-in-progress developer tree.
If you are running an actual release, or one of the stable branches, you are not affected.
The main cause for concern is if you are generating keys in some form on the developer tree.
Re: (Score:2)
I guess this is a problem (Score:2, Funny)
According to many people on this site almost every Linux user have now switched to FreeBSD because of Systemd.
There are/may be worse problems with -current (Score:5, Informative)
The -current is not a release — it is the trunk of the development tree. Using for anything important — such as data, that may be worthwhile enough for your enemies to hack for — is silly. Far worse bugs may exist in -current — or be introduced at any point.
Stick to releases [freebsd.org] — or one of the -stable branches — for anything, that's not about working on FreeBSD itself.
That explains hearthstone! (Score:2, Funny)
Why do I get both my 7 mana-cost cards on my first two draws?
Why does the best card in my hand always wind up being the card that gets discarded on random discards?
Why is the board-clear that I need always at position 30 in the draw pile?
It is because they built their server backend on FreeBSD!
It is all so clear now.
Re: (Score:2)
Re: (Score:2)
"Coming to terms with variance" == "learning to accept that the RNG Gods hate you"
Re: (Score:2)
Just make an offering of entropy and they'll be unpredictable again.
Non-news.... Bug is in CURRENT not STABLE (Score:5, Insightful)
Re: (Score:1)
Bleeding edge software has bugs?? what
Many people run CURRENT, so if they put their pubkeys on servers they could possibly be guessable. Try reading the article next time.
Re: (Score:1)
What!!! you don't regen keys everyday OMFG, what is the world coming to, AHHHHHHHHHHHHHHHHHHHHHH!
Re: (Score:1)
What!!! you don't regen keys everyday OMFG, what is the world coming to, AHHHHHHHHHHHHHHHHHHHHHH!
It's been a problem for months, I'm sure some people have generated keys in that time. Are you trolling?
Re: (Score:1)
What article... did you even follow the link? don't talk shit, current is essentially beta, lots of people run beta, but you don't use it for production... BSD specifically tells you this when using current.
Yeah I submitted the article. I'm not saying it's running on production. I'm saying the keys made by people running current are.
Re: (Score:1)
Well then, you are a ignorant fool. Everybody using FreeBSD should know CURRENT is the development (alpha) code line. Running alpha code means following the development mailing lists and keeping up with SCM submissions. If you run that in a non-development environment you need to find another career, maybe basket weaving is more appropriate for your intelligence level.
There have been lots of broken things in CURRENT, including filesystems. If you base anything on that code, such as build filesystems or gen
Re: (Score:3)
current is essentially beta, lots of people run beta
Actually, current is alpha. Release candidates are beta. "Beta" means it is done, except for testing, and, while there may be bug fixes, there will be no new features. That is not what "current" is. It is under active development.
Re: (Score:3)
Bleeding edge software has bugs?? what
Many people run CURRENT, so if they put their pubkeys on servers they could possibly be guessable. Try reading the article next time.
Yes they do, yes they could, no it's not news, it's on the current branch... In true BSD style i'm going to say RTFM: https://www.freebsd.org/doc/en... [freebsd.org] Current is not intended for production, end of.
Re: (Score:1)
I'm not saying it's running on production. I'm saying the keys made by people running current are.
RE:Random Number Generator Broken (Score:2, Insightful)
All of these problems will be solved when systemd integrates Rand
Re: (Score:2)
That seems like a perfectly sensible step on their way to world domination.
http://en.wikipedia.org/wiki/R... [wikipedia.org]
Re: (Score:2)
What, it has not done that yet?
Re: (Score:2)
It'd be more interesting to ask how this passed code review. Expecting code to remain static out of a fear of touching it is unreasonable. Expecting a solid code review process, by contrast, is very reasonable.
Re: (Score:2)
It did not. This is a developer snapshot.
Re: (Score:2)
This is a developer-snapshot, not any release quality one. As some developers are running bleeding-edge kernels, it is right to notify them, but no normal users are affected.
The question why this code was touched is a valid one though, as is the question who touched it.
How bad was the bug? (Score:5, Funny)
This seems like an odd bug to have happen, how bad were the effects? Just 'weaker' randomness, or without randomdev_init_reader do the random routines just return the same series of pseudorandom digits every time?
Also, obligatory Dilbert reference [dilbert.com]
Re: (Score:2)
obligatory XKCD reference [xkcd.com]
Living in a state of sin (Score:2)
"Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin." -- John von Neumann
"Random" (Score:3)
When blackboxed, even "return 5" is indistinguishable from a true random number generator.
People want noisy numbers, not random numbers. Which is a good thing, because a true random number generator will never exist.
But it doesn't have SystemD (Score:3, Funny)
So who cares??
An OS RNG? (Score:1)
Why would you expect the OS to solve your random number problem for you? It's software. It has no means to know what platform it is really running on and no means to understand the min-entropy of any input it sees. It is the wrong thing in the wrong place and it cannot 'guarantee' secure random numbers unless it gets guarantees of min-entropy sources from the hardware it runs on and uses it correctly.
If you hardware doesn't offer a hardware RNG with specific claims for min-entropy or computational bounds on
Re: (Score:2)
waaaay off base. hardware is far more difficult to audit (tools that cost hundreds of thousands) vs software. openbsd does things right here. they use hardware as an additional (but not the only) source of entropy.
Hardware, or more accurately, the physical world is the only source of entropy. Software is incapable of making entropy. It is deterministic. It can run entropy extraction algorithms to turn entropic data from physical sourced into uniform, cryptographically secure random numbers, but the entropy out of an extractor is strictly less than or equal to the entropy in. So software cannot itself be a source of entropy.
This isn't an issue of off-base/on-base. It's an issue of fact.
Re: (Score:2)
/dev/random has been part of UNIX for ages. It's part of the system, and expected to be there. The kernel developers take it seriously, because most UNIX software that needs random numbers uses it.
If you don't trust it, that's fine, but pretty much all UNIX software uses it - and UNIX runs the 'net. Certificates are generated using it. If you want to avoid it, install Windows and unplug your internet connection.
Re: (Score:2)
/dev/random blocks on most unix derived operating systems unless you go to some measures to feed the kernel with a continuous supply of data claiming to be entropic.
Certificates generated with software that trusts /dev/[u]random is what led us to the "Mining your Ps and Qs" problem. Google it if you aren't familiar.
Even if you have a good source of entropy on your platform, the odds are high that neither the OS nor RNGd will use it. On some popular Linux distributions I've used, RNGd fails silently at boot.
Re: (Score:2)
Sure, you've got good points about failures in /dev/random. Surprise, there have been problems - just like there's been problems with pretty much all code everywhere at some time.
But what exactly do you expect kernel developers to do? /dev/random exists, and a lot of stuff uses it. It's expected to be there. Kernel developers (especially BSD developers, who tend to view UNIX much more conservatively than Linux developers) are going to make sure that the service is available and as bug-free as possible.
Re: (Score:2)
Kind of like how it
Re: (Score:2)
>The OS is responsible for being a reliable source of trusted entropy.
Yet it cannot possibly be that. The OS has no entropy. It is not a source of entropy. Physical processes are sources of entropy. The OS might be able to demultiplex a source of physical entropy to share it out amongst multiple processes, but as has happened time and time again, we've seen operating systems fail to do exactly that because the OS has no knowledge of whether it's inputs are entropic, and when they are not, you get data th
Re: (Score:1)
And yet, on many systems running many different operating systems, the OS is able to do precisely that: provide a reliable source of entropy. This is of course because many channels which only the operating system can watch do contain a lot of entropy and the operating system is able to mix the data up to create a nice random number, better than applications can. An implementation bug in a non-release version of FreeBSD does not disprove that. Furthermore, it is a given that in modern times random numbers a
Re: (Score:2)
>And yet, on many systems running many different operating systems, the OS is able to do precisely that:
You should be concerned about the situations where it doesn't work, which are probably in the majority of Linux deployments. The people taking advantage of low entropy crypto systems don't just focus on the ones that work.
FreeBSD isn't doing the 'wrong' thing. It's doing all it can in a bad situation. However my application code can know where to go look for well defined sources of entropy and use it
Re: (Score:2)
Re: (Score:2)
The entropy is coming from nothing but hardware. Your software is running on the hardware. You typed in that post using hardware. If you don't trust the hardware, why do you think an entropy pool implemented in software will save you?
Re: (Score:2)
where we think the OS will solve a problem it cannot solve in the general case, is brittle and fails frequently
If your OS is so bad that you don't trust it's entropy, then STOP using that OS. If you can't, then sucks to be you, it's a crap OS and the programmers should die in a fire.
Re: (Score:2)
>whether dedicated hardware generators
Those would be the ones that cell phone chip companies buy from IP providers right? Like this one..
http://www.discretix.com/accel... [discretix.com]
Go look at the the picture. It's a ring oscillator that is sub sampled, to turn the accumulated phase noise of the RO into random bits. The process introduces serial correlation. This is normal.
Then it goes into a "Von-Neumann" whitener. This is a bias correction algorithm. Put in biased bits, get out unbiased bits. Lovely, it doesn't sa
Re: (Score:2)
>The exceptions are newer CPU instructions which can be used directly from user-land processes.
I may have an unusual level of familiarity with those.
Alternate strategy... (Score:3, Informative)
I say this because my home server faces the world and allows anyone who wants to, to make an attempt to login via ssh on port 22. You may say this is completely insane, but my logs suggest it isn't that bad. The overwhelming majority of all attempts on my system attempt to come straight in as root. As everyone knows, you can very easily disable root login in your sshd.conf file which leaves the person on the other end completely incapable of knowing whether or not they ever got your root password right as the response is the same.
The end result is they make their 10,000+ attempts in a couple hours, then leave and never come back. They might take a few parting shots at other well known account names but they won't get in that way either.
Re:Alternate strategy... (Score:5, Insightful)
my home server [runs public facing sshd] on port 22. You may say this is completely insane.
Gasp. How extremely uncommon.
Just don't use keys for remote ssh logins.
What? Why?
But based on my experience [...] it appears they [...] may even be counter productive.
And that is why exactly? None of your post explains that or seems to have anything to do with key-based login at all.
As everyone knows, you can very easily disable root login in your sshd.conf file which leaves the person on the other end completely incapable of knowing whether or not they ever got your root password right as the response is the same.
As happens when key-based logins are used. Your point being?
Re:Alternate strategy... (Score:5, Informative)
Sweet Jesus, at least install Fail2Ban and block an IP for 24 hours after 3 failed attempts.
Shhhhhhhh (Score:3)
Re: (Score:1)
Field day (Score:1)
I have never seen a bunch of Linux users get so excited over a bug in a development branch before.
This is a DEVDELOPER SNAPSHOT (Score:3)
As apparently nobody bothered to find out, this is a bleeding-edge developer snapshot, not anything that was in any way "released", hence no normal users are affected.
I do have two questions though:
1. Why was that code touched in the first place?
2. Who touched that code and broke it?
It may be simple incompetence (it usually is), but it may also be a mole in the FreeBSD project. It should be ascertained that the person that did this did so in good faith. Still, some level of shaming is required even then to make people pay attention when they touch security-critical code and keep their fingers off it unless they have the required level of skill and understanding and there is actually a real need to touch that code.
Re: (Score:2)
Well, that is a plausible explanation. And it was caught in time.
Re: (Score:2)
The "code was touched" in order to bring some new features in. Here is the commit for that branch to /dev/random r 273872 [freebsd.org]
Re: (Score:2)
Excellent. This is a completely satisfactory explanation.
I still hope the people involved have learned to be extra careful with /dev/urandom, as it can break so very many things in ways that are not readily obvious. Unfortunately, problems with CPRNGs that break the security of applications and systems have a long history and people working on these need to be reminded time and again of that.
Anyways, thanks for the info!
My D&D Characters all Wrong?! (Score:1)
Do you mean to say that the tool behind the die roller for my D&D characters is all wrong?
I have to re-roll my characters all over again!