New Vulnerabilities in Portable OpenSSH

An anonymous reader writes "The OpenSSH team has uncovered multiple exploitable vulnerabilities in the days-old portable release of OpenSSH. That's right folks: time to patch *again*. 3.7.1p2 is now available. Instructions and mirror list here. Please note that this vulnerability only affects *portable* OpenSSH--so if you are running OpenBSD, you're safe. This vulnerability apparently has to do with PAM, so you can use the 'UsePam no' option in your config file. Info on the advisory here and here."

Non-standard configuration

[grub]

From the article: At least one of these bugs is remotely exploitable (under a non-standard configuration, with privsep disabled)

Priviledge Separation saves the day again. I think this is a testament to the forward thinking of the OpenBSD and OpenSSH people: they know that human error introduces potentially exploitable bugs, hence the work that went into PrivSep to minimize the risk.

"The lengths some people will goto to try and damage Theo's pride" [slashdot.org] Most moronic submitter comment ever.

PAM is not in by default

[Anonymous Coward]

Before we all panic, note that PAM is not in the default build.

It's also not in slackware builds (thanks Patrick).

Re:I don't understand

[SwansonMarpalum]

Portable OpenSSH refers to OpenSSH running on some system which is not OpenBSD

Re:I don't understand

[Compenguin]

From the portable openssh website:
"Normal OpenSSH development produces a very small, secure, and easy to maintain version for the OpenBSD project. The OpenSSH Portability Team takes that pure version and adds portability code so that OpenSSH can run on many other operating systems (Unfortunately, in particular since OpenSSH does authentication, it runs into a *lot* of differences between Unix operating systems)."

Re:I don't understand

[V. Mole]

OpenSSH is OpenBSD specific. "Portable SSH" is what everybody else uses. In other words, the OpenBSD developers (quite reasonably) don't spend any effort making SSH portable off of OpenBSD, and sometimes use OpenBSD specific functions. Other people then spend the time/effort to make run on Linux, etc. There are features (such as, presumably, PAM support) that are not in the core OpenBSD version.

Re:A better solution

[Anonymous Coward]

What, you mean the same lsh that was just exploited two days ago [slashdot.org]?

Frankly, I think you'd have better luck searching the web for 'ssh'. [verisign.com]

OpenSSH in RedHat 9 and others

[avij]

The RH-supplied latest OpenSSH (3.5p1-11) doesn't seem to accept the "UsePam no" directive that was suggested as a workaround, so if you go ahead and add that line to your /etc/ssh/sshd_config and say "service sshd restart", SSH will complain about an invalid configuration option and refuse to start. Just for your information..

Re:A solution? Read advisory

[Anonymous Coward]

Advisory [openssh.com]

Subject: Portable OpenSSH Security Advisory: sshpam.adv

This document can be found at: http://www.openssh.com/txt/sshpam.adv

1. Versions affected:

Portable OpenSSH versions 3.7p1 and 3.7.1p1 contain multiple
vulnerabilities in the new PAM code. At least one of these bugs
is remotely exploitable (under a non-standard configuration,
with privsep disabled).

The OpenBSD releases of OpenSSH do not contain this code and
are not vulnerable. Older versions of portable OpenSSH are not
vulnerable.

2. Solution:

Upgrade to Portable OpenSSH 3.7.1p2 or disable PAM
support ("UsePam no" in sshd_config).

Due to complexity, inconsistencies in the specification and
differences between vendors' PAM implementations we recommend
that PAM be left disabled in sshd_config unless there is a need
for its use. Sites only using public key or simple password
authentication usually have little need to enable PAM support.

RedHat boxes are safe

[menscher]

Just to alleviate some of the panic, RedHat boxes are safe [redhat.com].

Re:OpenSSH in RedHat 9 and others

[ZerothAngel]

Well, the advisory states that "Older versions of portable OpenSSH are not vulnerable." So it's probably not much of a worry anyway.

Re:OpenSSH in RedHat 9 and others

[virtual_mps]

More importantly, the problem only affects OpenSSH 3.7p and 3.7.1p, so adding "UsePam no" to a 3.5p installation is unnecessary.

Re:OpenSSH in RedHat 9 and others

[Eric Seppanen]

According to Redhat Bugzilla bug 104917 [redhat.com], Red Hat has never shipped openssh 3.7, so they're not vulnerable to this. No workaround or fix is needed.

Re:RedHat boxes are safe

[Jhon]

Is that accurate? I read that as saying "With the version shipped with RH and RH Enterprise" -- which is an OLDER version. Doesn't that mean that if an RH user has updated SSH to a newer version, they are vulnerable?

Re:Is the default config file safe?

[Ratcrow]

No!

From the top of sshd_config:

"The strategy used for options in the default sshd_config shipped with OpenSSH is to specify options with their default value where possible, but leave them commented. Uncommented options change a default value."

In other words, simply uncommenting the line changes nothing -- the default is shown commented. For the SRPMS of OpenSSH-3.7p1, UsePAM is set to Yes.

RPM's for Red Hat 7.2, 7.3 and 8.0

[corz]

I created these a little earlier today:

http://projects.standblue.net/rpms/openssh/3.7.1p2 / [standblue.net]

Enjoy.

More fixes than PAM

[Soft]

According to the Changelog:

- [e-mail] 2003/09/18 08:49:45
[deattack.c misc.c session.c ssh-agent.c]
more buffer allocation fixes; from Solar Designer; CAN-2003-0682;

it would seem that in addition to the PAM patch, there are more buffer management-related fixes which didn't find their way into 3.7.1p1 but prompted Debian to make a third update [debian.org] to ssh. One may want to update even on OpenBSD or with PAM disabled.

Re:JEBUS

[Ed Avis]

One of the principles behind OpenBSD (and therefore OpenSSH) is full disclosure of security vulnerability. They don't want to lie about how secure the software is or try to conceal things from you. Therefore the vulnerability reports (and fixes) are published as soon as possible. In practice, I think they do wait to have a patched version before announcing the bug.

To repeat a post above...

[Paulo]

Nimda:
Patch Released: August 15, 2001
Major Exploit Starts: September 18, 2001

SQL Slammer Worm:
Patch Released: July 24, 2002
Major Exploit Starts: January 25, 2003

MS Blaster Worm:
Patch Released: July 16, 2003
Patch Released: August 11, 2003

So, how was this about "ignoring the problem" again?

Re:Non-standard configuration

[Oestergaard]

Unfortunately, privilege separation does not work with with OPIE, the one-time password system.

So either you run privsep, or you run OTP.

Without OTP, you'd be crazy to log on to your ssh box from anything but a trusted terminal (e.g. your office workstation or your personal laptop). Without OTP, you cannot log on from a net cafe or anything like that, if you're just slightly security concious.

So I'm stuck with privsep and no OTP on some machines, and OTP without privsep on another (which I need to be able to log on to from untrusted terminals).

It sucks, but it's the best we have for now, it seems.

I do look forward to finally getting that 2.6 SELinux toy box set up ;)

Re:Non-standard configuration

[Oestergaard]

Interesting.

Is that using PAM?

My box is on Debian 3.0 - the explanation I saw at that time was that the combination of PAM and the extra OPIE password query wouldn't work with privsep because of some too simplified assumptions in SSH/privsep about what would be asked by the system and what would be submitted by the user.

Or something like that. I set it up half a year ago and to be honest I don't remember the details - I just remember that at that time OPIE+privsep was a no-go, at least on a Debian box with PAM.

It sounded like it was something that could be fixed fairly easily - I was lazy and didn't bother to try doing that myself, and just went with no privsep to get a working setup. I suppose someone could have fixed whatever the problem was, in the mean time. Or maybe the problem somehow exists on Debian and not on NetBSD - I'm sure there is a reasonable explanation somewhere ;)

Thanks for letting me know. I should check up on it.

Re:Time for a new spin on security practices?

[Short Circuit]

Sure, dependencies can be an issue. But saying that upgrading and patching *nix platforms does not produce any mind-numbing dependency issues is simply a self delusion.

I used to run Debian Woody (stable). At the cost of not getting the latest features, I got all the stability I could ask for, with all of the security patches backported. Now I run Debian Sid (unstable), which tends to have dependency problems, but I at least have control over them. And if worse comes to worst, I can install the patches personally.