While it is a good thing that people are aware of the issues pointed
out by Ulrich Flegel with regard to crossing security boundaries and
forwarding ports across them, this is hardly a new issue nor is it
really an SSH problem. This and the more general TCP/IP port
forwarding issue have been discussed on the SSH mailing list several
times over the past two years.
The "attack" is really just saying that if you have a corrupt server,
and you forward X11 to it, it can connect to your local X server.
This is true and avoidable in every scenario I can think of where your
server is allowed to make any X11 connections to your X server. You
can only avoid it by not allowing X11 connections from the remote
machine at all.
It is good that Ulrich has written an "exploit" to illustrate the
problem, but the same "exploit" works equally well even if you don't
use SSH at all (assuming you still want to allow X11 connections).
X11 forwarding is definitely not a feature that should be entirely
disabled. It is extremely useful for a lot of people. However,
disabling it has been made as flexible as it possibly can be for those
who do want to disable it. SSH has for a long time provided options
to disable X11 forwarding
- at compile time
- in config files
- on command line.
>From a firewall administrator's standpoint, SSH X11 forwarding or port
forwarding does not open any new hole with respect to what users can
do (it does make certaing things a bit easier though). If you allow
telnet, rlogin, or any other login protocol, any competent programmer
can write a program that listens for connections on port 6000 and
writes/reads the data to/from stdin/stdout. At the client end,
another program telnets/rlogins to the server machine and sends all
traffic to/from the local X server. This does not require any special
privileges from the user. SSH just makes this easier. But it does
not open any new hole there.
Yes, there are environments that want to disable X11 forwarding by
default. But for a vast majority of users, SSH X11 forwarding
provides a major security improvement by not sending the authorization
cookie or the X11 packets in the clear.
Tatu
-- SSH Communications Security http://www.ssh.fi/ F-Secure Internet Security Solutions http://www.datafellows.com/f-secure/ Free Unix SSH http://www.cs.hut.fi/ssh/Message-ID: <58966149@lorraine.braunschweig.netsurf.de> Date: Tue, 30 Sep 1997 21:48:29 +0100 Reply-To: Ulrich Flegel <Ulrich.Flegel@braunschweig.netsurf.de> From: Ulrich Flegel <flegel@MAIL.BRAUNSCHWEIG.NETSURF.DE> Organization: None Subject: SSH/X11 vulnerability To: BUGTRAQ@NETSPACE.ORG
------------------------------------------------------------------------ SSH/X11 Vulnerability September 1997 ------------------------------------------------------------------------
Systems affected: All systems running Secure Shell (SSH) clients and X11.
Description: In a firewalled environment insecure protocols normally are not allowed to cross network boundaries and to enter the protected network environment.
SSH is able to relay arbitrary TCP connections, especially X11 traffic is mediated per default.
If SSH connections may leave the protected network environment insecure protocols may unconsciously be imported and exploited.
Impact: Everyone who can access foreign .Xauthority files on SSH servers is able to access the X server of the SSH client machine. The client machine is open to a variety of attack scenarios while the SSH session exists.
Exploit: See References for a detailed description of the exploit.
Solution: Client side (administrator): Build SSH clients with "--disable_client_x11_forwarding". Set "ForwardX11" to "no" in "/etc/ssh_config". Set up packet filters which allow connections destined for port 22 only if originated from a privileged port.
Client side (users): Set "ForwardX11" to "no" in "~/.ssh/config". Apply the "-x" option when using "ssh".
Server side (administrator): Build SSH servers with "--disable_server_x11_forwarding". Set "X11Forwarding" to "no" in "/etc/sshd_config".
References: For a more detailed description of the vulnerability, its consequences and countermeasures see:
http://home.braunschweig.netsurf.de/ ~ulrich.flegel/pub/ssh-x11.ps.gz
----------------------------------------------------------------------- Copyright (c) 1997 Ulrich Flegel, Ulrich.Flegel@braunschweig.netsurf.de -----------------------------------------------------------------------