OpenSSH 3.4 [LWN.net]

OpenSSH 3.4 was released just five days after the release of version 3.3. The release closes "at least one major security vulnerability"; upgrading to 3.4 is recommended. Please see the vulnerability report for a list of security alerts from distributors as they become available.

OpenSSH provides a critical entry point to many systems on the net; this could be nasty. If you plan to wait for an update from your distributor, please consider setting UsePrivilegeSeparation yes or ChallengeResponseAuthentication no in sshd_config to avoid the vulenrability. UsePrivilegeSeparation is only available in OpenSSH versions 3.2 or 3.3. Setting ChallengeResponseAuthentication may impeed customary access for some or all of your users.

Version 3.3 firmed up "privilege separation" support, and made it the default. Essentially, privilege separation works by splitting the ssh server into two cooperating processes. One process is charged with talking to the network; it runs without privilege. The other process sits back, makes decisions, and hands out privileges when it's convinced that is the right thing to do.

The end result is that there is little to be achieved by compromising the "front line" process. Even if somebody does discover a vulnerability in that code, it can not be used to gain access to the system. The privileged process, by virtue of its simplicity and its separation from the network, is far easier to verify as being truly secure.

The 3.4 release closes the serious vulnerability described in advisories from OpenSSH and ISS. The vulnerability prompted a week long code audit by the OpenSSH team which resulted in "many other fixes. We believe that some of those fixes are likely to be important security fixes."

(Log in to post comments)

OpenSSH 3.4

Posted Jun 27, 2002 9:32 UTC (Thu) by nix (subscriber, #2304) [Link]

Note that privilege separation support doesn't work with compression on Linux 2.2 (or below) kernels, because this needs anonymous mmaps: the same applies to other Unixes where these are not supported.

(Solar Designer has provided a patch that fixes this, but as far as I know it's not in openssh proper yet.)

See bug #285, and its myriad duplicates, on bugzilla.mindrot.org.

OpenSSH 3.4

Posted Jun 27, 2002 14:41 UTC (Thu) by garloff (subscriber, #319) [Link]

The whole process of keeping the problem secret towards Linux
distributors and publishing the vulnerability without prior
notification of the distributors can at best be be given the
label "poor handling". The Linux distributors were forced to
upgrade to the PrivSep enabled openssh-3.3 despite some un-
resolved issues with that feature and despite the fact the
the time did not allow for proper testing.

Now, it turns out that most Linux distributors are not affected
by this vulnerability in the default configuration as most did
not compile S/Key or BSDauth support in. And no distribution
and only few admins will have enabled the PAMAuthenticationViaKbdInt
which is off by default.

Still, the distributors had no choice as they did not know.
Except for Alan, maybe, whose reaction towards Theo from the
backward perspective now seems justified and reasonable.

One could speculate that Theo could not stand the thought that
only OpenBSD and not Linux would be affected, when OpenBSD is
allegedly so much more secure than the Linux versions out there.
So he made the Linux distros spread uncertainty to their customers
as well and -- nice side-effect -- force them into a design that
he considers (and which probably is) more secure but which has not
yet received enough test coverage.
He was successful: The Linux distros shared the mess around the
vulnerability with him; despite the fact that most were not even
affected.
Excellent service to Microsoft! Thanks, Theo!

And I'm not even speaking of the thousands of security aware
admins and security people at distributions that he made nervous
and who have missed some hours of sleep.

And to confirm Alan: We don't trust you Theo! Never again!