Re: SSH LocalForward

long-morrow@CS.YALE.EDU
Sun, 03 Aug 1997 09:11:14 -0400

Kristof Van Damme <aeneas@sesuadra.org> wrote:
>But when I put:
>
>LocalForward 80 remotehost:80
>
>in my ~/.ssh/config file and connect to the remote host I don't get the
>error and port 80 is opened on the localhost (an httpd was not running,
>the port must be available). When I connect to it I get a normal
>redirection to remotehost:80 over the secure channel. This means however
>that a non-root user is able to open privileged ports on the localhost and
>redirect them. Is this normal? I checked it on Linux and Solaris. > >Aeneas

You're right. It it definitely a bug in ssh. I was just able to
set up port redirection from port 81 on my local machine to port
80 on a remote machine using the above.

The implications are a bit scary -- on a machine where telnet or rlogin
is normally disabled an ordinary user could set up ssh port redirection
of the telnet or rlogin service to a machine under their own control. A
user with ordinary privileges could "run" a Web server on a machine
not currently running a server bound to port 80 by redirecting port 80
to another host, etc.

ssh only has this ability because it is normally installed setuid.
Turning off the setuid bit on the ssh client program doesn't appear
to impair the normal operation of ssh and scp, but it definitely
turns off the hole which allows privileged TCP/IP ports to be forwarded.

I recommend turning off the setuid bit ('chmod u-s /usr/local/bin/ssh').
until the posted code fix is installed and tested.

In fact --unless you are willing to peruse source code for bugs and
will always install patches asap when bug reports come in -- I'd
recommend leaving the setuid bit off the ssh client executable for the
long forseeable future just to be on the safe side. It means that you
will have to live (on Unix/Linux hosts) without passwordless
connections (both the (1) ordinary 'rhosts' and the (2) 'RSA rhosts'
authentication methods because (1) ssh won't be able to prove that it
is running as a privileged process by opening up a connection from a
port under 1024 on the local host via which to transmit the username of
the current user, nor (2) will it be able to read the local host's
private from the file /etc/ssh_host_key which is normally only readable
by 'root').

You can still use the following authentication modes with a non-setuid ssh:
1. 'user' RSA public key authentication
2. Unix password login over the ssh encryption connection.
3. S/Key or other non-reusable stronger (than Unix username/
reusable password) authentication -- if you have installed the
appropriate modules or modifications into the remote sshd
(ssh server).

H. Morrow Long, Yale Univ IT ISO -Info Technology Services Info Security Officer
175 Whitney Avenue, New Haven, CT 06520-8276, (203)432-1248(voice) 432-0593(FAX)
INET: http://pantheon.yale.edu/~long/ mailto:Morrow.Long@yale.edu
PAGE: (203)370-3081, (800)347-2574, mailto:1165469@pager.mcb.com PIN# 1165469