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."
since 1999 when I first started using OpenBSD for security-based boxes, I've never had an issue.
That you know about.
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
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.
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.
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?
CLI paste? paste.pr0.tips!
Sweet Jesus, at least install Fail2Ban and block an IP for 24 hours after 3 failed attempts.
You are in a twisty maze of processor lines, all alike.
There is a lot of hype here.