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: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.

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

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.

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.