Log in

No account? Create an account
Lord Yupa

February 2010

Powered by LiveJournal.com
Danger Mouse

Theo can bite me. [or OpenSSH "vulnerability"]

I will admit from the start, that Theo de Raadt annoys me. I've seen and participated in e-mail discussions with him before, and I've nearly never seen a pleasant discussion where he's involved. I don't like him.

However, the whole thing with the recent OpenSSH security vulnerability really annoys me. His poor handling of the "exploit" has cost a lot of people a great deal of time, effort, and hard work, and for many of us, unnecessarily so.

Here are the basic facts, as I understand them:
  • All versions of OpenSSH < 3.4 are vulnerable to exploit. (Rumor has it that versions prior to 3.0 are not vulnerable, but I've not been able to verify this.)

  • Theo de Raadt has been telling everyone that they must upgrade to OpenSSH 3.3 immediately, while admitting that this does not fix the security hole (it does reduce the impact it has, though).

  • Theo (falsely) claimed that there was no patch or fix available for this security exploit, and wouldn't be until a new release of OpenSSH was released.

  • Thousands of people were left with very little information, and were forced to spend the time and effort to protect their systems, upgrade OpenSSH, then test and verify it. Additionally, OpenSSH 3.3 has known bugs on many platforms (compression doesn't work on all operating systems, including Linux 2.2.x kernels, PAM support isn't complete, and breaks on many systems, etc).

  • The claim that all systems making use of OpenSSH < 3.4 are vulnerable is untrue.

  • The vast majority of systems out there using OpenSSH are in fact not vulnerable by the default setup. (Although, OpenBSD is. It's also the only major distribution that is is vulnerable.)

  • Your OpenSSH installation is only vulnerable to this security problem if you have RSA based rhosts authentication turned on, AND you have S/KEY authentication turned on. Both of these options must be compiled in and enabled (most default setups leave both of these disabled, even if compiled in)

  • You can ensure that your systems are safe and secure from this bug simply by editing the sshd_config (in /etc/ or /etc/ssh/), and adding the directive: ChallengeResponseAuthentication no, or if you already have that directive listed, change it to no. That's correct, no additional patching or upgrades are needed.

  • As far as I can tell, the only real reason that Theo didn't release this fix sooner, was so that he could ram his Privilege Separation feature in OpenSSH >= 3.3 down our throats. While I think this is a good feature in the long run, I seriously dislike running a program, especially one like ssh, that was released less than a week ago, on a production server. Especially when there are known bugs with it. I doubt all of these bugs have been fixed in OpenSSH 3.4.

I hope I haven't annoyed everyone too much with this little rant, but a someone who spent a considerable amount of time upgrading half a dozen machines in the past two days, only to find out that none of them were ever even vulnerable to this exploit, I'm really pissed off.

[Note: This was cross-posted to a couple of places, and I apologize if you see it more than once. I know it's a rant, but my main purpose for writing it was to distribute information on the OpenSSH vulnerability, and how to fix it, so that no one gets bit by the exploit. If anyone feels I shouldn't have posted it as I have, please let me know and I'll refrain from doing so next time.]


I have a feeling the real reason is this (or as JWZ put it, "___0___ DAYS WITHOUT AN ON-SITE INJURY!")

If OpenBSD is going to have a remote security hole then damnit, everyone has to suffer!
Glad to see I'm not alone in hoping he gets a good solid whack (or three dozen) with something substantially heavy.

Also, it apparently only affects SSH2

3.3/3.4 bugs.

Well, one of the things that annoys me the most about this is known bugs that are currently biting me, due to this upgrade. I'm not worried about the Privilege separation features being buggy. . . you're correct, it is fairly well tested. But I still don't want to introduce any major changes to an important production system, if I can help it. I want that box stable and trouble free, which means the only changes I want are bugfixes, and even then, I want the smallest changes that will fix the bugs.

Specifically, two of the systems I had to upgrade were using 2.2.x kernels. OpenSSH > 3.3 has problems with this, specifically, it won't work with compression enabled. When you're dealing with dial up connectoins, compression makes things a *lot* easier to deal with. Because Theo is a dumbass, my systems are now working less well, and less efficiently, than they were before. And what's worse, both of these systems (running Debian/Potato) were never even vulnerable to this bug!

I wasted my time and work, and my systems are now runnig worse than they used to, and for no good reason at all.

Re: 3.3/3.4 bugs.

Nope, there aren't any real issues with the latest 2.2.x kernels (other than the fact that they don't support some features). The two machines that still have 2.2.x kernels have them both because I don't want to deal with making a kernel change, and because there are a few userland programs that would have to be upgraded to support a 2.4.x kernel, and we need these machines rock solid, period, right now. I'm not willing to make any changes that I don't absolutely have to. (Both boxes are heavily used, and a lot of people are dependant on them working, and working exactly as they currently do.)

As for my os/distribution choice, I currently prefer Debian/GNU Linux. I've tried just about everything under the sun (Including NetBSD, FreeBSD, and even a few days with OpenBSD), but I have yet to find anything that agrees with me as well as Debian. Their package management is by far and away the best I've found, their setup's are as stable and solid as a rock, and they are very good about security updates.

I have actually reverted both systems to the old version of OpenSSH, by the way. The version these systems are running is based on OpensSH 1.2.3, which doesn't support SSH2, and is not vulnerable in any way to any of the exploits recently discovered.


I agree with you, regarding the general quality of OpenSSH. I was hesitant for a long time, and I think I was one of the last people who ditched the non-free sshd for OpenSSH.

And it is a damn fine piece of software. With regards to the software itself, I have no complaints at all. Even this security bug doesn't bother me that much (no code is perfect).

What bothers me is how poorly Theo's response to the bug was. If he would have simply told us that turning off S/KEY authentication will provide a valid work-around for this specific bug, then I could have done that, and rested easily knowing that at least for the moment, I won't wake up to find a box rooted.

Then I could evaluate OpenSSH 3.4, once released, and determine if I wanted to upgrade to it, and when. Additionally, then I could evaluate Privilege Separation, the permanent coded fix for this problem, and the current bugs plaguing OpenSSH 3.3/3.4, to determine whether it would be advantageous for me to upgrade my systems.

And as things stand now, no, it wasn't worth it. I wasted a lot of time and effort that I could have better spent doing other things, and I have systems running sub-optimal now.

As for your security illustrations, I agree with you. A good security setup can greatly minimize the impact that this kind of problem can have on a network. However, two points.

First of all, a number of the systems I administer provide shell accounts to people for various purposes. For most of them, this requires nearly unrestrected access to port 22/ssh, as people from anywhere could be accessing the machine. I'm forced to rely on the security of SSH and the rest of the system.

Secondly, much research suggests that many, if not most, security breaches occur from within a company. In other words, that box of yours that's inside the firewall and just got rooted, was prolly done, not by some insanely clever cracker from the Internet who found a way in, but by someone working at your company. In that situation, leaving a box open to a root exploit and counting on the firewall to protect it is a Really Bad Idea (tm).