linux
*G* at least confesses that (even if openSSL-dev is not withouth guilt)
The SANS Institute yesterday took the highly unusual step of issuing a yellow alert over a vulnerability in the cryptographic functions of Debian, the Linux distro that underpins Ubuntu. Earlier this week Debian warned that the use of a cryptographically flawed pseudo random number generator in its implementation of OpenSSL …
Dr. Peter Venkman: I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?
Dr. Egon Spengler: Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.
Dr Ray Stantz: Total protonic reversal.
Dr. Peter Venkman: Right. That's bad. Okay. Important safety tip. Thanks, Egon.
"Any OS that isn't up to date on patching is a risk."
You miss the beauty of this particular vulnerability.
You can patch your software and *still* continue to use the vulnerable keys. One you've patched, every ssh user on a Debian/Ubuntu has run regenerate their keys. Ever tried to get *every* user on a multiuser machine to do anything?
Even better, patching your system and regenerating users keys still leaves the machines you've ssh-ed to using a public key vulnerable. All machines running sshd and accepting public keys have to identify and delete the keys from Debian/Ubuntu systems in /home/*/.ssh/authorized_keys. This is why we're starting to see security advisories from operating systems which lack the fault, such as CentOS.
To summarise: Debian/Ubuntu systems: delete all keys, including user keys, and start over. If I were system administrator of a multi-user Debian/Ubuntu machine in addition to patching and regenerating all system keys I'd blatantly delete all /home/*/.ssh, let the chips fall where they may, deal with irate users, but sleep knowing my machine was secure.
Other systems: to be safe delete all imported keys, particularly /home/*/.ssh/authorized_keys. Be careful not to lock yourself out whilst taking these steps. You will get some annoyed users. Live with it: if they were going to fix it themselves they'd have done it by now. You can always restore the .ssh directory of the One Decent User from backup.
Flame: because I'd like to toast people at both Debian and OpenSSL. Despite their "better than you" unapologetic attitude they've unleashed the biggest threat to Linux systems in years.
First off let's remember it was a Debian screw up, not a wider problem. Even if the problem had been wider it would have been app related not OS related and that particular app runs on a lot of OSes.
Now to main main point: Debian has a patch stability and security record that is the envy of many a company. Just shows that no one is perfect I guess.
You have to regenerate any ssh or ssl keys or certificates generated on your system. Just updating doesn't do diddly squat.
The "news" is that for the last two years, every single person who generated a key of any given length on a Debian-derived system using OpenSSL got one out of a grand total of 32,768 possible keys. Which is a tiny pool, and stunningly easy to brute force. There are already lists of all the possible keys for 1,024 bit and 2,048 bit lengths floating around, and 4,096 will be done soon. So any server out there which granted any kind of privileged access to anyone using a key generated with a Debian-derived distro in the last two years has to be shut down and tested for vulnerable keys, all the vulnerable keys removed and their authors notified to replace them. That's probably thousands and thousands of servers. Is that enough news for you yet?
Hang on, this was raised internally in 2006 and has only now been released to the community at large / patched.
Um, I thought the advantage of open source is that it's peer reviewed so that once a weakness was found it was patched. This has been known since 2006?! Seriously?! Makes MS look like patching saints...
After the bashing about MS only patching things once discovered by external security people (rather than patching when they know about a hole), this looks pretty bad.
Actually, Linux is used on more than just your desktop.
Having being rolling out Linux servers and OpenVPN networks for the past 5 1/2 years, we have a major problem.
Luckily due to some foresight, we are protected more than most people in our situation, but just to give you an idea as to our problem, take a typical company; how long will it take you to generate 100 new OpenVPN certs, package them up and distribute them to 100 home workers, about 30% of whom require to be talked through the install process...
Don't get me wrong, Linux totally rocks, but don't under-estimate the seriousness of this problem.
This has been a critical situation for a few days, and it isn't that it 'potentially' produced predicable keys, but that is DID produce VERY predictable keys.
I used umbongo for a couple of months last year because everyone was raving about it, and promptly switched back to fedora when 8 was released. During that time of umbongo use I generated my DSA key... Which I now find the private key quite well... public!
feel sorry for the poor guys who runs svn+ssh servers that rely on this!
go here http://metasploit.com/users/hdm/tools/debian-openssl/ for some detail
"Got a patch for Ubuntu two days ago now that automatically regenerated any keys."
Host key only. Unfortunately doing this may make it look like it fixed the problem :( No, if you have them, you also need to regenerate all user keys, and remove weak user keys from authorized_keys lines on any systems you added them to (if those systems haven't already removed them for you). For some, this is a huge job. And if those systems don't accept passwords, and they have already been updated to debian-patched-openssh which has blacklisted the only key you can login with, getting in to fix things can be "a bit of a problem".
There is also a really nasty MITM situation with SSL. Web browsers _really_ need to start blacklisting keys for https...
Depends. You see, there's this nice 'from=' option which you can apply to individual keys in your authorized_keys; and if you're using that (ooh, static IP, shiny), you're a bit more secure even with a weakly-generated key since it'd require more effort from the attacker.
I'd still replace any weak keys.
It is quite big thing really.
But, it is about Debian not Linux.
A package maintainer in Debian thought to patch OpenSSL many many moons ago, and no one has noticed the problem till now.
Sure, the fix once the problem was outed was fast, and that is a good thing, but the lesson to be learned is that any security alteration requires a few people to authorize the change, hopefully and I am fairly sure they will, Debian will make changes in the future to lower the chance of this happening again.
And of course this is not an obvious vulnerability and to exploit it would take skill and a lot of time, it is not like the door was left open, just the randomness in the key generation was not as strong as it should have been.
Once the vulnerability is in the wild though, people will be looking at how to exploit it, so upgrading and changing keys is very advisable. If you were using Debian for the last two years, and you were in a security sensitive area I would imagine you would be cursing yourself right now - but then you should have been on OpenBSD shouldn't you.
I'm a Linux developer, but every time I see something like this I feel more and more alienated from the Linux community. This flaw in particular baffles the mind. Think about it: The "security" people maintaining Debian's OpenSSL apparently don't understand how their own code works, to create and apply this sort of patch. Yet nobody thinks that this is a problem.
Nobody. Not at Debian. Not at Ubuntu. Not at any of the infinite (and infinitely sickening) derivatives of these two distributions. Probably not even their users, who are trusting these clearly incompetent "volunteers" with their valuable data.
If there's a moral in this, it's for the developers more than anything else. Trust upstream to do the heavy lifting -- it's their code, and they should know how it works. (I would recommend exactly the opposite to users regarding the distribution maintainers...)
Were this some little "voodoo" program -- written by someone who didn't understand the code -- I could understand patching "funky" code, or wanting to do extensive testing/debugging -- although again, that should be handled at the individual program's level, not the distribution. But OpenSSL is developed by computer security experts. If something in the code looks bizarre, but it's from a competent programmer, chances are it was done deliberately. If it ain't broke, don't fix it; if you don't know how it works, LEAVE IT ALONE.
I may be wrong, but when I googled this the other day, I'm pretty sure I saw several posts in OpenSSL's own mailing list archives about the apparent uninitialized memory "bug". At least a couple of them were well before this madness with Debian started. I think. Anyway, if that's the case, you'd think they could have at least googled the "problem" themselves before "fixing" it.
Mine's the one with the electromagnetic degausser (you can never be too sure about destroying insecure keys...) And the cattleprod, in case I ever meet any Debian people.