Slashdot Mirror
FreeBSD-Current Random Number Generator Broken
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."
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.
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.
Wouldn't it make more sense to patch the kernel to make the correct function calls then update to a kernel with more changes that may not be tested/stable for a given usage scenario?
Silence is a state of mime.
since 1999 when I first started using OpenBSD for security-based boxes, I've never had an issue.
That you know about.
According to many people on this site almost every Linux user have now switched to FreeBSD because of Systemd.
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 — or one of the -stable branches — for anything, that's not about working on FreeBSD itself.
In Soviet Washington the swamp drains you.
Bleeding edge software has bugs?? what
All of these problems will be solved when systemd integrates Rand
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 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?
"Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
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.
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.
For every problem, there is at least one solution that is simple, neat, and wrong.
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
I do not deploy Linux. Ever.
I just checked on openbsd.org, and I loved the FAQ section! ...
4.13 - Common installation problems
4.13.1 - My Compaq only recognizes 16M RAM
4.13.2 - My i386 won't boot after install
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.
So who cares??
http://saveie6.com/
Comment removed based on user account deletion
"Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin." -- John von Neumann
/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.
Those who can't do, teach. Those who can't teach either, do tech support.
Just don't use keys for remote ssh logins. I know, keys are supposed to be all that any more. But based on my experience fending off billions of script kiddy attempts from my home system, it appears they aren't worth the effort and may even be counter productive.
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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
The OS is responsible for being a reliable source of trusted entropy. There are many ways to create strong pseudo-random numbers, some are faster than others, but all can be strong. Random numbers are a complex issue that should be implemented once and implemented well. Doing random in user land is a horrible idea and has been a reoccurring issue over the years. You also run the issue that software may not get upgraded, but the OS can. Single point of responsibility and all that jazz.
Kind of like how it is recommended not to implement your own version of TCP and let the OS handle it. Could you imagine if random software implemented their own network stacks?
>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 that is highly correlated between systems.
The whole set up, where we think the OS will solve a problem it cannot solve in the general case, is brittle and fails frequently. A user land program, invoked by a user, is in no better or worse situation when it comes to doing the right thing, except that the user can run code that is particular to the environment, whereas the OS is necessarily written to work on all platforms, including fully synchronous embedded platforms with zero entropy until the ethernet is up.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
/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. You have to go and check if you need it to be there. I have a massive bloody linux server farm at my corporation and not one of them has RNGd running and /dev/random blocks after a few bytes. I assume this is normal. It is a symptom of the messed up model we have where we trust software that is not in a position to do what we ask of it.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Netcraft Confirms FreeBSD is dying
Facebook is too confusing!
Don't you have a Twitter link to share?
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
That seems like a perfectly sensible step on their way to world domination.
http://en.wikipedia.org/wiki/R...
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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I have never seen a bunch of Linux users get so excited over a bug in a development branch before.
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 are necessary and functionality that is needed by a lot of different applications should be provided by the OS. Even if what you said were true, saying ‘just shove it down to userspace’ doesn't solve the problem; you should be pushing for better RNGs in OSs instead.
What, it has not done that yet?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It did not. This is a developer snapshot.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This guy is the low hanging fruit that keeps all those automated attacks from China from developing something more sophisticated :P Not that i'm suggesting security through obscurity is the only way or anything... just an extra line of Darwinian defence.
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!
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
>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 appropriately. We have the math on extractor theory. We have the math on secure PRNGs. The algorithms are easy. The sourcing of the entropy is the problem to solve and OSs demonstrably do it in a way that doesn't work on a wide spectrum of deployments.
>you should be pushing for better RNGs in OSs instead.
No. I'm pushing for better RNGs in hardware, which I can reasonably claim to have done something about.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
>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...
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 say anything about auto-correlation. The link to the Von Neumann paper is broken, but the Yuval Peres paper is just as illuminating. I quote..
1. Introduction. A source produces independent biased random bits {x_sub_i}^n,i=1 with p = Pr[x_sub_i = 0] ne 1/2, q = Pr[x_sub_i = 1].
So the Von Neumann balancer and the iterated Yuval Peres version have undefined properties for dependent inputs. They require independent inputs. But that isn't what the circuit is generating. They're most definitely auto-correlated.
However I've done the test and I can confirm that a VN whitener will make the result worse. not better when you put auto-correlated data into it.
This is how most of the published IP designs work. They are all wrong by design. /dev/random isn't magic. It needs its input to be entropic. Synchronous embedded systems regularly don't meet this requirement. PCs regularly don't meet this requirement early in the boot cycle.
Good RNGs exist. I've designed a few. Others have designed many. But bad RNGs and naive kernel code outnumbers the good ones.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
>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.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
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.
No one trusts hardware anymore. It can be used to mix with the entropy pool, but it should never be used directly.
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. You might not like /dev/random, but it's not going to go away any time soon.
I don't use Linux for anything important (I'm a BSD guy these days - Linux is for desktops in my opinion), so I don't know what to tell you about rngd. I have noticed that a lot of "system" level stuff seems to be on the backburner compared to nifty convenience features. If you need a working rngd, it's up to you to find a working configuration and push it to your servers. Treat it like ntpd or any other service that requires site-specific configuration. I do know that I would expect something like random number generation to be working flawlessly in BSD, but Linux today... I can't say I'm surprised.
Those who can't do, teach. Those who can't teach either, do tech support.
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?
I should use this sig to advertise my book ISBN-13 : 978-1501515132.