OpenSSH's client drops all privileges before the user is asked for a
password, so there is really no need to panic and send ads to this list
-- especially since this thread not at all related to SSH-1. However,
if you are afraid of SSH-1 you can simply turn off protocol 1 support
in OpenSSH and happily use SSH-2 only.
This is not a protocol issue but an implementation issue, and is not
related to which protocol is used in "OpenSSH". I just took a quick look
at this in "OpenSSH 2.3.0" source. On line ssh.c:624, it says:
/*
* Note that some legacy systems need to postpone the following call
* to permanently_set_uid() until the private hostkey is destroyed
* with RSA_free(). Otherwise the calling user could ptrace() the
* process, read the private hostkey and impersonate the host.
* OpenBSD does not allow ptracing of setuid processes.
*/
permanently_set_uid(original_real_uid);
While OpenBSD may be safe from the risk of attaching with debugger, there
are other systems in use that are vulnerable. Several years ago,
when I wrote the original code for SSH1, I did a quick study on whether
various systems allow debugging the process after restoring the user's
privileges. I found several widely used systems that did allow attaching
with a debugger after the process had relinquished suid privileges.
(Unfortunately, I no longer remember which systems were affected.)
I did a quick test now (at only a few systems), and the situation
seems to have improved. At least Solaris 2.6, Digital Unix 4.0,
linux-2.2.12, NetBSD 1.3.2 were safe, and presumably newer versions of
these are also ok. I did not check other platforms. However,
there may still be older systems in use where it is not safe to relinguish
the privileges. Old installations in production live suprisingly long
without upgrades.
On those systems that are affected by the problem, this results
in private key compromise, allowing impersonation of any user on the
server and impersonating the server itself for password stealing or
man-in-the-middle attacks. The attacks are relatively simple to implement
in practise.
To eliminate the risk, SSH1 keeps the extra privileges until
authentication is complete. SSH2 approaches this differently; the client
is not suid at all, and there is a small, easier to analyze helper
application that accesses the local host key. Thus, even if there was a
bug in the client, it holds no sensitive information.
I would recommend something similar for "OpenSSH", either moving the call
back to where it was in SSH1 (i.e., after authentication) or alternatively
changing the architecture to something similar to that in SSH2. It is,
in my opinion, a lesser evil to face the unknown risk of keeping the suid
rights a little longer than to include a serious known vulnerability for
some systems, even if the affected systems are slightly older.
Tatu
SSH Communications Security http://www.ssh.com/
SSH IPSEC Toolkit http://www.ipsec.com/
SSH(R) Secure Shell(TM) http://www.ssh.com/products/ssh
Moreover, we never received a report on this or a similar problem and
it's not reproducible for us, so it seems your setup is broken (do you
have a stack backtrace).
-m
On Fri, Feb 09, 2001 at 09:59:34AM +0100, Tomasz Kuniar wrote:
Ssh client is suid, so it could be real problem. Must check source...
On Sat, Feb 10, 2001 at 02:42:23PM +0200, Tatu Ylonen wrote:
SSH2 also fixes fundamental security problems in the old SSH1 protocol.
SSH1 is DEPRECATED, and people are strongly encouraged to move to using
the SSH2 protocol.
The latest version of SSH2 is ssh-2.4.0, available from
ftp://ftp.ssh.com/pub/ssh. SSH2 is completely free for any use on Linux,
FreeBSD, NetBSD, and OpenBSD, as well as for use by universities and
charity organizations, and for personal hobby/recreational use by
individuals. (For commercial use, please see http://www.ssh.com/.)
