[5329] in bugtraq
Ulrich Flegel's SSH/X11 "vulnerability"
daemon@ATHENA.MIT.EDU (Tatu Ylonen)
Fri Oct 3 02:07:18 1997
Date: Fri, 3 Oct 1997 01:17:55 +0300
Reply-To: Tatu Ylonen <ylo@SSH.FI>
From: Tatu Ylonen <ylo@SSH.FI>
X-To: ssh@clinet.fi
To: BUGTRAQ@NETSPACE.ORG
Ulrich Flegel writes:
> SSH/X11 Vulnerability September 1997
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
-----------------------------------------------------------------------
