[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

www.debian.org question and Re: SSH/X11 vulnerability



First, I was just wondering about the 'www.debian.org' site and what's
happening with it.  Specifically, the 'Debian Packages' menus seem to be
really out of date.  I found that to be a very useful resource.  Is there
relief in sight?

Next, here is the reply I saw from the SSH author re the recent 'SSH/X11
vulnerability' posting to this list.  It's interesting even if you're not
running SSH ...

>From owner-ssh@clinet.fi  Fri Oct  3 07:35:42 1997
Received: from hauki.clinet.fi (root@hauki.clinet.fi [194.100.0.1]) by
hutcs.cs.hut.fi (8.8.5/8.7.3) with ESMTP id HAA13854; Fri, 3 Oct 1997
07:35:41 +0300 (EET DST)
Received: (from majordom@localhost)
        by hauki.clinet.fi (8.8.6/8.8.6) id GAA26994
        for ssh-outgoing; Fri, 3 Oct 1997 06:21:49 +0200 (EET)
X-Authentication-Warning: hauki.clinet.fi: majordom set sender to
owner-ssh@clinet.fi using -f
Received: from ssh.fi (ssh.fi [194.100.44.97])
        by hauki.clinet.fi (8.8.6/8.8.6) with ESMTP id AAA24254
        for <ssh@clinet.fi>; Fri, 3 Oct 1997 00:18:32 +0200 (EET)
Received: from pilari.ssh.fi (pilari.ssh.fi [192.168.2.1])
        by ssh.fi (8.8.7/8.8.7/EPIPE-1.12) with ESMTP id BAA07733;
        Fri, 3 Oct 1997 01:18:03 +0300 (EET DST)
Received: (from ylo@localhost)
        by pilari.ssh.fi (8.8.7/8.8.7/EPIPE-1.10) id BAA08209;
        Fri, 3 Oct 1997 01:17:55 +0300 (EET DST)
Date: Fri, 3 Oct 1997 01:17:55 +0300 (EET DST)
Message-Id: <199710022217.BAA08209@pilari.ssh.fi>
From: Tatu Ylonen <ylo@ssh.fi>
To: bugtraq@netspace.org, ssh@clinet.fi
Cc: f-secure-ssh-support@DataFellows.com, mjos@ssh.fi,
        Ulrich.Flegel@braunschweig.netsurf.de
Subject: Ulrich Flegel's SSH/X11 "vulnerability"
Organization: SSH Communications Security, Finland
Sender: owner-ssh@clinet.fi
Precedence: bulk

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
-----------------------------------------------------------------------

---
Roy Bixler
The University of Chicago Press
rcb@press-gopher.uchicago.edu


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: