Re: SSH & xauth

[david () PYBUS DEMON CO UK (David Pybus)]

How is this different to a malicous user (with root privilege) just taking a
copy of the cookie out of the connected users .Xauthority file, placing this
information into their own .Xauthority file and then connecting to the
X-server on the SSH client's side. I do not think that there is anything
particularly significant about the possibility of Trojanning xauth. The
significant point here is that, by default, an SSH client gives too much
trust to the server it is connecting to. Perhaps consideration should be
given to changing this default such that a parameter has to be passed to SSH
when a session is started to allow X11 connections, without this parameter
X11 connections are not allowed.

The issue here has nothing to do with xauth and everything to do with the
trust granted by SSH. If you use SSH to connect to boxes that you don't
trust or can't be confident are secure then you should be concerned about
this. The major threat I see here is that a rooted box could be used to gain
access to a secure box through the SSH tunnel, even if the secure box is
behind a firewall that only allows outbound connections.

Yours, David Pybus.

-----Original Message-----
From: Bugtraq List [mailto:BUGTRAQ () SECURITYFOCUS COM]On Behalf Of Brian
Caswell
Sent: 24 February 2000 22:32
To: BUGTRAQ () SECURITYFOCUS COM
Subject: SSH & xauth

The default SSH configuration for SSH1 and SSH2 allow for remote
controlling of X sessions through X forwarding.

All children of the SSH connection are able to tunnel X11 sessions
through the X tunnel to the client X11 session.  This is accomplished
by running xauth upon logging in.

If xauth is replaced on the server by a malicious program that does
both of the following:
 - runs xauth, adding in the "correct" information allowing the
   children of the session to tunnel X11 programs through the SSH
   session
 - runs xauth, adding in the "malicious" information, allowing a
   malicious source to tunnel X11 programs through the SSH session.

With the added data in .Xauthority, a malicious source can fully control
the client X session.  The malicious source can then do most anything to
the X session, from logging keystrokes of the X session, to taking
screen captures, to typing in commands to open terminals.

The only thing that is required for the client system to be compromised
is for the client to remotely log via ssh (with X11 forwarding enabled)
into a compromised server.

Allowing X forwarding seems to be turned on by default in SSH1, SSH2,
and OpenSSH.

To fix this "issue" add the following lines to the SSH client
configuration.  ($HOME/.ssh/config or ssh_config)

        Host *
          ForwardX11 no

Discussions of security flaws within X11 have been going on for years.
The "issue" in SSH X11 forwarding is not new.  SSH has added to the
security of X11, but by no means does the use of SSH secure X11.

--
Brian Caswell <cazz () ruff cs jmu edu>
If I could load the world into vi, the first command I would use is:
%s/Windows NT//gi