[NEWS] Upcoming OpenSSH Vulnerability (Privileges Separation)

From: support@securiteam.com
Date: 06/25/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Tue, 25 Jun 2002 09:05:17 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Upcoming OpenSSH Vulnerability (Privileges Separation)
------------------------------------------------------------------------

SUMMARY

A security vulnerability in OpenSSH has been found, the vulnerability has
not been yet disclosed but from the information available up to now,
enabling OpenSSH's sshd(8) privileges separation feature stops the exploit
from working properly.

DETAILS

Immune systems:
 * OpenSSH version 3.3p with privileges separation enabled

OpenSSH 3.3p was released a few days ago, with various improvements but in
particular, it significantly improves the Linux and Solaris support for
privileges separation. However, it is not yet perfect. Compression is
disabled on some systems, and the many varieties of PAM are causing
problems.

However, everyone should update to OpenSSH 3.3 immediately, and enable
privileges separation in their SSH daemons, by setting this in your
/etc/ssh/sshd_config file:
 UsePrivilegeSeparation yes

Depending on what your system is, privilege separation may break some SSH
functionality. However, with privileges separation turned on, you are
immune from at least one remote hole.

Note however that OpenSSH version 3.3 does not contain a fix for this
upcoming bug.

The basic idea behind privilege separation is that OpenSSH sshd(8) has
something like 27000 lines of code. A lot of them run as root. However,
when UsePrivilegeSeparation is enabled, the daemon splits into two parts.
A part containing about 2500 lines of code remains as root, and the rest
of the code is shoved into a chroot-jail without any privileges. This
makes the daemon less vulnerable to attack.

ADDITIONAL INFORMATION

The information has been provided by <mailto:deraadt@cvs.openbsd.org>
Theo de Raadt.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages