OpenSSH Vulnerability Disclosed, Version 3.4 Released

Dan writes: "OpenSSH 3.4 has been released and will be shortly available on all mirrors. All versions of OpenSSH's sshd between 2.9.9 and 3.3 contain an input validation error that can result in an integer overflow and privilege escalation. OpenSSH 3.4 fixes this bug." And kylus writes: "The previously mentioned vulnerability in OpenSSH has been disclosed by ISS X-Force today on the BugTraq list. This is a potential remote root compromise, and while there is a workaround, it's advised that users upgrade to version 3.4 as soon as they can."

Comments

Workaround here:

[codewolf]

locate the "ChallengeResponseAuthentication" line in /etc/ssh/sshd_config (typically) change to :
"ChallengeResponseAuthentication no" and restart sshd

Was there ever a working 'sploit?

[toupsie]

I have read much about this problem in OpenSSH and fearing the worst...checking logs to see how often my SSH version was scanned. However, as far as I know, I haven't had any break ins using a SSH exploit. Thank God for TCP Wrappers, at least that helps when you find out about these things.

Did any one of the many black hat groups out there actually work up a exploit or was this caught in time that it was just a possibility of being exploited?

New Slogan!

[skinney]

"One remote hole in the default install, in nearly 6 years!" you can see it here: OpenBSD

~Shane

Re:New Slogan!

[AndrewHowe]

It was suitably humble of them to admit it and update their homepage.
Unfortunately, one remote hole is all you need. Such is the Unix nature.

Re:New Slogan!

[bbh]

Yeah, it was probably the guy with the exploit that updated the webpage :P

bbh

Cheers, Theo

[gorf]

All that you need to do, as far aas I understand it, is turn Challenge/Response authentication off (which nobody uses anyway). So the line in /etc/ssh/sshd_config reads:

ChallengeResponseAuthentication no

and then restart the daemon.

Big deal.

I don't see any need to upgrade anything. Yes, privilege separation is nice in terms of future security, but I prefer the (more likely) known stability of software that has been in use for a while.

Debian security policy is that vulnerability fixes are backported (to avoid adding anything that could cause instability or further insecurity); this was made impossible by Theo's and ISS' advisory which lacked any details about the exploit. This may have been justified had the exploit not be able to be prevented by a simple configuration change (in order to give administrators time to prepare an upgrade their systems), but not for this.

Cheers, Theo, you just cried Wolf for the entire community. If there ever is a hole major enough that everyone should (or might want to) upgrade to a version which is by nature immune rather than give away the exploit by releasing a patch, noboby's going to believe you now, and probably not anyone else either.

Re:Cheers, Theo

[transient]

This is a problem throughout most of the security community, and it's the reason I don't subscribe to bugtraq anymore. At the risk of starting a flamewar, my impression of people who are really into security as a group is that they have an over-inflated sense of their own importance. Every seminar I attend, every publication I read, and every security expert I speak to tells me the same thing: that hordes of hackers (and now terrorists, too) are out to melt my hard drives and make me lose $1 million a minute.

This is simply not true. I believe that security is important, and that there are certain measures sysadmins should take in order to keep undesirables out of their systems. But every time somebody finds some tiny little problem in a program, suddenly the world screeches to a halt, everyone panics, and we get bombarded with headlines and emails demanding that we upgrade immediately or our data centers will explode. Oh, and by the way, don't forget to put two pages of credits on the exploit's "whitepaper".

The result of all this horn-tooting is that I don't care anymore. Whenever someone utters the words "security advisory" I simply stop listening, because 99% of advisories are crap.

What is ChallengeResponseAuthentication?

[rherbert]

How does this authentication method work? I just disabled it, and I was still able to log in using my RSA keys and password authentication (which are the only methods I use). The documentation says it's for s/key authentication, but what is that? How common is this authentication method, and who would use it?

Re:What is ChallengeResponseAuthentication?

[diamondc]

s/key auth. is a one time use password system. first, you'd generate some passwords and write them down.the passwords only work once. They come in handy if you're in an insecure network.

http://www.openbsd.org/faq/faq8.html#SKey

Re:Why was it kept hush hush?

[Tyrall]

Nope, the big delay wasn't vendors didn't believe 'it' was real, they had no clue what 'it' was.

They were told to release an upgrade to a version that broke existing functionality, was largely untested, and were also told that it didn't directly fix the issue anyhow. The were told this without any details of what the vulnerability was, or even if it would affect them (and it turns out that nearly every distro will be unaffected).

I don't blame any distro for being a little wary and asking for more information. I believe Debian summed it up very well in their advisory.

Easy workaround

[garett_spencley]

Don't use SSH. Switch to telnet instead....

ChallengeResponse... oh please! Telnet's never had these problems.

(note for the humour impared: this is a *joke*).

--
Garett

okay, let me get this straight.

[Dr. Awktagon]

Okay, busy morning but glancing at the news, here's what I see:

There was a bug in the challenge/response code between 3.0-3.2.3. In fact, it's an "overflow" according the advisory. This means to me, it should be a fairly easy fix. Quote:

It is possible for a remote attacker to send a specially-crafted reply that triggers an overflow. This can result in a remote denial of service attack on the OpenSSH daemon or a complete remote compromise.

In addition, this overflow only works when SKEY and/or BSD_AUTH is enabled. But this seems to be "not enabled...in many distributions". How about Linux? However, OpenBSD has BSD_AUTH enabled (natch). Quote:

At least one of these options must be enabled before the OpenSSH binaries are compiled for the vulnerable condition to be present. OpenBSD 3.0 and later is distributed with BSD_AUTH enabled. The SKEY and BSD_AUTH options are not enabled by default in many distributions.

And now to add insult to injury, the 3.3 I installed yesterday has a new different buffer overflow, so I have to jump to 3.4 now (does it have any new bugs too?)

I don't like to jump versions on production machines. I like to fix what's running for minimum disturbance.

Can someone please explain why this vulnerability was handled this way? Why wasn't there a maintainance release that just fixed the @#$@#% problem?

I know: since the bug affected so many people, Theo thought it would be better to bury the problem in his privsep code, instead of fixing it and letting the blackhats run "diff" and find it for an easy 0-day-'sploit. In other words, security by obscurity, just like the big guys. That stinks, if you ask me.

On the other hand, I charge by the hour when I upgrade my client's machines. So thanks Theo! $-)

For gods sake

[Mr_Silver]

Never have I seen such a pathetic display of whinging. Bug was found, 3 choices:

1. Tell you lot nothing, get the fix done and released (in which case you wouldn't have known about it until the fix came out).

2. Or tell you there is a bug, you can fix it temporarily by doing this until we get the fix out. In which case you decide either to follow him or do nothing (because after all, thats what you'd have been doing if nothing was said)

3. Or say, we have a bug, it's this and this and this is how you exploit it and then you lot all either scramble to install something else or sit around praying you don't get rooted whilst they compose a fix because now everyone and their dog know exactly how to exploit it.

Geeesh, be thankful he actually told you number 1. Next time, I think he should probably stick with number 2 and just tell you when the fix is out - at least then you can't whinge about it.

Slackware not vulnerable

[volkerdi]

Slackware is not affected by this security problem. You need BSD_AUTH, S/KEY, or PAM to have a potential problem (PAM is still not verified), and we've never compiled in any of those options, nor are they options in a default build. So, you could just keep using a version with working compression, just don't include those options.

More simple is usually more secure.

How to fix ...

[joe_fish]

Just add a line to your /etc/ssh/sshd_config like this:

CheckPasswords false

And then reboot your sshd.

Finally mail me, and I'll check that you really are safe. Oh and don't about slashdot users giving you bad advice you can be sure to only get accurate information here.

Affects who?

[MSG]

So, what do we know about who is affected? Immediately after reading the announcement, I checked Red Hat Linux's build of OpenSSH. The configure script positively reports that the affected authentication mechanisms are not available. 'ssh -v' does not indicate that challenge-response authentication methods are available either. I imagine that other Linux distros are similar?

RHL configure output:
OpenSSH has been configured with the following options:
...
Smartcard support: no
S/KEY support: no
BSD Auth support: no

Re:Why was it kept hush hush?

[kevinank]

The rationale not exposing the exploit was that if the exploit became known then immediately there would be many thousands of machines that could be exploited. That would be bad, so the question became 'is there some way to disable the problem code without fixing the bug', then a bug fix can be delivered after without anyone getting hacked.

There were basically two ways to fix your configuration. One was simple, and actually the default on most systems. The other is a pain in the ass, but Theo likes the second method because it is aesthetically more pure; a better implementation of a security conscious application.

The distributions (who couldn't get any information about the nature of the bug, just the suggestion that they fix the pain in the ass way of using sshd) correctly figured that they were being railroaded and balked.

For what it is worth, privelege separation is a better architecture for a security concious program, but setting up a chroot jail and adding new users, along with the brokeness of several ports of the new privsep code especially in the area of pluggable authentication modules (ie: RedHat) means that although I now have 3.4p1 iunstalled on my boxen, I also have privsep turned off. Less pure, but I'm a pragmatist, not an idealist.

How soon until djbssh?

[GregGardner]

I can't wait until djb decides to write his own ssh. You can say what you want about djb and his personality, but he does know how to write some secure software. Sure, it's not the easiest thing to install and you have to create a boatload of users, but privilege separation has been in qmail since 1.0.0. Theo is getting around to it in v3.3? Never heard of any root compromises from qmail or djbdns. So hopefully this latest hole in OpenSSH has annoyed djb to the point of rolling his own.

Re:Why was it kept hush hush?

[epine]

Every choice in handling this matter carries a different consequence for different groups of people. Theo can't serve every group equally.

As it turns out, recent OpenBSD installations were exposed to this, where many other platforms were not exposed.

The first question Theo had to decide was whether to spread the information around before his own user community was protected. Of course every vendor thinks they are entitled to this information. No black hats here! No rooted systems here! Your secrets are safe with us. Tell enough vendors, your secret is certain to escape.

The next question to decide is whether to create a window of opportunity for his own user base to protect themselves before giving away anything of use to the black hat community.

He can't do this without admitting that there is a big problem here. But any further details he gives become clues for those who might try to discover the flaw themselves.

As it stood, he had an option to put forward which allowed his user base to protect themselves while giving nothing away to his black hat adversaries. privsep is a case of Doing The Right Thing. I'm sure Theo does get frustrated that vendors don't put a higher priority on Do The Right Thing initiatives.

On OpenBSD itself, privsep has been there quite a while and I don't think it would be considered untested in its nascient environment.

He couldn't very well suggest to his user base "disable challenge/response". That's like backing away from Mike Tyson.

What could he have done differently?

He could have informed his own user base to install the reasonably well tested privsep version *in advance* of informing other vendors of the actual problem in secrecy *after* he completed the actual bug fix patch. This would have meant keeping the patch secret for another week or two.

But instead he chose to put his boot up the ass of vendors who think that compatibility with PAM is more important than adopting a model which eliminates 90% of the future prospect for more of the same.

If Theo were entirely sane he wouldn't be doing what he's doing. Maybe he has your best interests at heart, but the same best interests you chose for yourself.

There are always people who have good reasons for delaying The Right Thing. In the long term, I think these people contribute more to the sorry state of security that brash actions by people like Theo.

If you invest your faith in Doing The Right Thing on the technical merits, I think you'll stick with OpenSSH. If you prefer the relationship model of working hand in hand behind the scenes, maybe you won't.