From: Rick Moen (rick at domain linuxmafia.com)
Date: Tue 25 Jun 2002 - 07:40:04 IST
Quoting Anders Holm (anders.holm at domain elivefree.net):
> Theo also states that PrivSep IS NOT A FIX but at least a workaround UNTIL a
> patch can be distributed. So, he is giving people a way of closing a flaw
> until it can be fixed. Since when is that bad? Sure, not ideal, but is it
> _so_ horrible?
Just in case it's useful, here's my analysis of the (technical) matter,
from a post elsewhere:
We're in a strange and somewhat unpleasant situation with OpenSSH:
Summary: Theo de Raadt of the OpenBSD Foundation (sponsors of the
portable OpenSSH version we use on Linux) warns that there's a
vulnerability in _all_ current OpenSSH daemon code, but that he can't
release details yet. Details will come out in about a week. Theo
recommends that everyone upgrade to the current 3.3p release anyway,
because of an unrelated but useful -- yet problematic -- feature it
supports called "privilege separation". Implementing his suggestion
means upgrading, then adding a new line to /etc/ssh/sshd_config and
restarting the daemon.
My comments: Traditionally, OpenSSH runs as an SUID-root binary,
forking off multiple copies as required. The new feature runs a base
copy as root, but most of the code runs as a non-root user, inside a
chroot jail. Thus, any remote exploits of the exposed code are less
likely to cause damage, as attackers will also face the separate problem
of escalating privilege and breaking out of the chroot jail.
The problem is that (1) de Raadt says enabling privilege separation
"may break some ssh functionality". de Raadt mentions PAM as a possible
problem area, and some have interpreted this as meaning that priv sep
breaks PAM. _But_ understand that de Raadt is just generically
anti-PAM: Nothing he's said has claimed specific breakage in that
area.[Note 1] (2) Since priv sep is very new code, it might not work
as designed. (3) The implication of all this is that the bad guys _may_
already have a not-publicly-known exploit and been using it for some
I've been running 3.3p on my Debian-testing (3.0 = woody) systems -- and
with priv sep enabled -- since this morning, with no problems so far.
Note that Debian 2.2 (I think?) and later has used PAM.
Sysadmins of Debian-testing systems should consider doing as I did:
1. Add this line to /etc/apt/sources.list to prospectively monitor
the new-ish Debian-testing Security Team package updates archive:
deb http://security.debian.org/ testing/updates main contrib non-free
2. Do "apt-get update ; apt-get dist-upgrade" to get the new versions.
3. Regrettably, because the Debian-testing Security archive puts
security ahead of version sync, the above's updating of Mozilla
will remove Galeon (if present). To get it back, retrieve the
version 1.2.5 packages of galeon and galeon-common from
ftp://ftp.debian.org/debian/pool/main/g/galeon/ Install using
4. Add this new line to /etc/ssh/sshd_config:
It's been widely _claimed_ that you also need to add this if running
on kernel 2.2.x:
I've had no problems in a day's worth of tests without that option,
but note it for completeness.
5. Restart sshd.
Works for me<tm>.
[Note 1:] As a late addition, MandrakeSoft has noticed one PAM glitch:
If you have an _expired_ password, sshd w/priv sep will close your
connection without giving you a chance to change your password. If
you've never enabled password-expiration, this isn't an issue.
-- Cheers, The difference between common sense and paranoia is that common sense Rick Moen is thinking everyone is out to get you. That's normal; they are. rick at domain linuxmafia.com Paranoia is thinking they're conspiring. -- J. Kegler
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:17:29 GMT