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

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?

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.

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?

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

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

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.