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

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.

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: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! $-)

Re:New Slogan!

[bbh]

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

bbh

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.

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.