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:Workaround here:

[Squeezer]

It will take whatever the default is that is programmed into the code, which is prolly yes. So in other words if its commented out its more then likely enabled. So uncomment it and change it to no.

I think I should start an OpenSSH remote root exploit of the month club.

Re:Workaround here:

[lunenburg]

That would indicate that the default is "yes", so if you want to disable it, you need to uncomment it and set ChallengeResponseAuthentication to "no". Then restart sshd.

Re:Workaround here:

[codewolf]

Actually, it is safe to make the ChallengeResponseAuthentication no change and restart, until you upgrade. But, you can not assume your version is vulnerable solely from the config file, it's a compile time option that makes it vulnerable, and this is different on many systems, so be safe, do the workaround until you upgrade.

Re:Why was it kept hush hush?

[zrodney]

it wasn't kept quiet for very long -- maybe a week
or two while solutions were implemented. The big
delay was that the vendors didn't believe it was
real.

well...

[ChrisMG999]

Well at least they are honest about it, and are trying to fix it. There's a company out here in redmond that could take lessons in honesty and security from them.

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

Re:Why was it kept hush hush?

[reelbk]

The details of the bug weren't disclosed immediately because there was no patch available. Now that it can be patched, most system will be protected from the script-kiddie storm. But, as usual, there are plenty of lazy and/or ignorant sysadmins who won't patch this.
It was hinted on bugtraq a while ago that a remote root exploit for SSH was discovered but would only be disclosed once patches were available.

Probable Reason for Theo's Approach

[Foresto]

Although it looks like Theo could have simply told everyone to disable challenge/response authentication, I'll venture to guess that he had a reason for not doing so. Consider that his original announcement was deliberately obscure, in order to avoid advertising the vulnerability to crackers, while vendors scrambled to patch their systems. If Theo had originally said "turn off challenge/response", all the crackers would immediately know where to look for the vulnerability, and the vendors would no longer have the head start they needed.

Here it is a few days later, the vendors have been given time to implement fixes, and we have disclosure. What are you people complaining about? Apart from the lack of social grace that he's famous for, I'd say Theo handled this about as securely as he could. Moreover, he did so by folloing the procedure widely accepted in the security community. Am I missing something?

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:What is ChallengeResponseAuthentication?

[Anonymous Coward]

RedHat 7.2 (at least) does not come compiled with support for either of the vunerable options.

/* Define if you want S/Key support */
/* #undef SKEY */

/* Define if you have BSD auth support */
/* #undef BSD_AUTH */

Re:What version does OSX ship with?

[mithras the prophet]

Welcome to Darwin!
[mithras:~] mithras% ssh -V
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f

and
cat /etc/sshd_config
...
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no

so it seems plausible that we're vulnerable, though I'm not sure.

However, this note indicates that 3.3p1 (and presumable now 3.4) compiles fine, including the privilege-separation option, without problems.

While Apple expects to have shipped 5 million computers with Mac OS X (and OpenSSH) by the end of the year, SSH is turned off by default. So this and future problems should affect only those who know what the hell SSH is...

Re:Cheers, Theo

[Matts]

You're trusting the same organisation that told us that the Apache bug wasn't exploitable on x86 Linux (and we later found out it was), that this is a trustable workaround?

No thanks, I'll upgrade my servers and enable priviledge separation. We may or may not see exploits that get around turning off the ChallengeResponseAuthentication bugs, but I'm not taking that chance.

Re:The good news ...

[volkerdi]

A lot of them compile in PAM, though. The bug involves keyboard-interactive mode plus one of the following: BSD_AUTH, S/KEY, or PAM.

Re:What is ChallengeResponseAuthentication?

[D_Gr8_BoB]

None of the Redhat 7.x series are vulnerable. To quote from the advisory:

OpenSSH supports the SKEY and BSD_AUTH authentication options. These are compile-time options. At least one of these options must be enabled before the OpenSSH binaries are compiled for the vulnerable condition to be present.

Both of these options are disabled unless specifically enabled with when configure is run. None of the Redhat 7.x OpenSSH spec files mention anything about BSD auth or SKey support, and so I conclude that they are not vulnerable.

Re:Cheers, Theo

[platypus]

You're trusting the same organisation that told us that the Apache bug wasn't exploitable on x86 Linux (and we later found out it was), that this is a trustable workaround?

Minor correction (only AFAIK, please correct me if I'm wrong):
ISS told us that the bug was not exploitable on any 32bit plattform, later we found out that this bug is exploitable on 32bit BSDs (free* and open* IIRC).
It's not exploitable on x86 linux.

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.

Yes: http://www.openssh.com/security.html

[David McBride]

(See subject.)

Re:Do I assume this is set at no?

[RollingThunder]

Generally, the defaults are displayed in the config file, as commented out instructions. In other words, the default is yes.

Re:Where are the vendor statements? FALSE

[Anonymous Coward]

Not true. My RH 7.2 and 7.3 systems default to "no". In fact, you can't set it to yes because support isn't even compiled in.

Re:Code Audits, the UNIX security model

[fw3]

suggest you go have a look at LSM - Linux Security Module ... see the .mp3 of the lsm presentation at this weeks kernel summit at lsm discussion. LSM creates hooks in the kernel functions which are security relevant (about 150) and can mitigate access to a couple dozen kenel data structures.

security model is too coarse grained: ... move towards ACLs, for example in NSA's SE Linux, as well as LIDS

Actually SELinux does not implement ACL's, but rather Type Enforcement. It also has potential (and experimental impementation) to implement MLS or other security policies / methods.

What type enforcement gets you is the ability to create highly fine-grained security controls, so that the program and user-security-context have privilege to execute critical functions and that privilege can be removed from the root user.

One of the debian SELinux implementers placed an SELinux system on the 'net with root-password / ssh access advertised. This is not a proof of safety, but in fact noone succeeded in escalating privilege.

As it looks like LSM is on track to be in kernel 2.6, at least the way is presently paved.

This all could have been avoided...

[chrsbrwn]

Meaning this brouhaha, of course...

Just to combat some of the misinformation that has been spreading around here:

• privsep is not a "new" feature... it has been available since OpenSSH 3.1p was released, almost 2 months ago. In that two months none of the various vendors and users who are whinging now appear to have bothered to help the openssh team test the privsep code and develop patches to make it work better.
• With privsep enabled, this hole, and any future root hole are made much more difficult, sometimes even impossible, to exploit. Privilege separation is just the right way to code network daemons -- postfix does it, apache does it, courier imap does it, qmail does it -- and now, openssh does it. It is a bit more complicated for openssh to do it because it needs to interface directly with some operating system facilities like authentication, PAM, etc that require root privileges.
• I installed 3.3p yesterday on all of my network facing systems, and will be upgrading to 3.4 as soon as Debian has it available -- I firmly believe in the concept of privilege separation, and will always seek out network daemons that use it.
• I thank the Debian team, OpenBSD/OpenSSH teams, Wietse Venema and the rest of the Postfix hackers, the mailman team, the GNU project, all the Linux kernel hackers, and anybody else who has contributed free software that I rely on to do my job for making my job as a sysadmin smoother than it might otherwise be. I know the alternative, because I am also responsible for an Exchange server, and I spend far more time patching that and making sure it is up to date than I do with any of my Debian servers.

Don't complain too much folks... you could have to do without a robust free ssh implementation.

CERT Advisory.

[hearingaid]

There's a full CERT advisory on the OpenSSH bug and the implications for your particular platform. Sysadmins, read it. Of course, you prolly all got it in your email like me, right? :)

ftp.openssh.org is getting hammered right now... sigh.