SSH & xauth (fwd)

Sat Mar 4 04:08:02 EST 2000

I have a suggestion that I think would be useful to implement.
People who have seen the Firewall Toolkit's X proxy will find this
suggestion familiar.  The fwtk provides a small proxy that users set their
DISPLAY to.  Whenever a new connection is initiated to that proxy, the
proxy pops-up a dialog box on the user's real DISPLAY.  The user must
agree to accept that incoming connection before the proxy will forward the
data from it.

The ssh client could be made to, whenever an X tunnel was opened, run an
external dialog program, before the client would accept the tunnel.  
Depending on the exit status of that program, the connection would either
be allowed on rejected.  Presumably this functionality would be optional
(but perhaps enabled by default).

Of course there is a tendancy for users to treat dialog boxes as a reflex
test and to click them without reading them.  However, this mechanism does
provide a way for cautious users to enable X forwarding without blindly
allowing all X clients to connect.

Comments, ambitious coders?

On Mon, 28 Feb 2000, Gary E. Miller wrote:

> Have you guys been following the SSH discussion on Bugtraq lately?
> 
> I like their idea the X forwarding should be OFF by default on the
> client.
> 
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
> 	gem at rellim.com  Tel:+1(541)382-8588 Fax: +1(541)382-8676
> 
> ---------- Forwarded message ----------
> Date: Fri, 25 Feb 2000 21:52:15 -0500
> From: Robert Watson <robert at cyrus.watson.org>
> Reply-To: Robert Watson <robert+sec at cyrus.watson.org>
> To: BUGTRAQ at SECURITYFOCUS.COM
> Subject: Re: SSH & xauth
> 
> This is a very round-about way of observing that allowing X11 forwarding
> from a client to any untrusted server (by any means -- sshd, xauth, common
> accounts, poor file permissions, compromised kernel, etc, etc) with the
> current SSH clients results in security problems (which you observe).
> 
> What's more curious is that in OpenSSH, which I observed some time ago,
> the default configuration is to enable X11 forwarding in the client and
> disable it in the server.  This is, of course, backwards, as the client is
> the one accepting risk by forwarding X11, not the server.  :-) 
> 
> If you search back a few years in the bugtraq archives, you'll see that
> one suggestion for dealing with this, and still allowing X11 forwarding
> from untrusted clients, is to use the Xnest server, limiting access by the
> ssh client to that DISPLAY.  As I observed at the time, Xnest was probably
> not designed with this use in mind, and as such is probably ``breakable,''
> meaning that a pursuaded party might be able to gain access to the proper
> display through exploiting weaknesses in the Xnest server.  I have not
> audited the Xnest code to verify that this is or is not the case.
> 
> I believe at the time, Alan Cox responded with information about using the
> Broadway extensions to limit access by specific applications to other X11
> applications, the X event queue, etc.  These messages were circa 1997, and
> should appear in bugtraq archives.
> 
> Presumably the correct configuration is for clients to disable X11 by
> default, and only have it enabled specifically by the user via appropriate
> flags to ssh, or via the config file.  You could imagine a more
> comprehensive interface to new host key adoption that also inquired as to
> a trust level for X11 forwarding using Broadway, etc.  In this manner, the
> user could specify ``limited'' access that would be sandboxed, not
> allowing access to screen data, X event queue access, etc, ``full,'' or
> ``none.''  With a little imagination, you could even imagine it spawning
> an Xnest to generate a sandbox for remote access.
> 
> I would conclude by observing that this is *very* old news--the only new
> news is that it has not yet been ``fixed.''  Of course, there's a decent
> argument that many consumers of SSH are the kind of people who also
> blindly accept new hostkeys without verifying fingerprints or using a PKI,
> so this kind of default won't help them at all, just causing frustration.
> :-)
> 
> If you want another puzzling OpenSSH tidbit, it's that the CheckIP option
> is enabled by default in the base implementation.  It has recently been
> turned off in the FreeBSD version for the following reason (which was
> rejected by OpenSSH developers shortly after OpenSSH was released). 
> 
> The CheckHostIP feature introduces automatic modification of the known
> hosts key file to include the IP address of the host after connecting by
> name.  This option introduces unnecessary modifications of keying material
> entries, and can cause spurious keying errors following IP address
> changes, especially in a dynamic DNS/IP allocation environment.  When a
> user requests a connection by-name, the key storage should be by-name, as
> SSH is not aware of whether or not the name/key binding is persistent. 
> Presumably, just as the user is responsible for performing by-name key
> verification and management, the user should also be responsible for
> managing by-number key verification and management. 
> 
> This also causes management problems for hosts employing centralized
> ssh_known_hosts entries--SSH replicates the key from the central file into
> the user's personal key file using the IP address to index the key.  If
> the IP of the host is a variable IP, putting the IP into the centralized
> file makes no sense, but SSH will take the liberty of replicating the
> keying material unnecessarily.  If a host key now changes, and the
> centralized file is updated to reflect it, SSH will now generate warnings
> as its spuriously replicated key no longer matches up.
> 
> You can even imagine DNS-based spoofing causing some problems, if combined
> with IP spoofing, as ssh-by-ip to a spoofed host would not generate an
> unknown key warning, instead, it would connect with full trust.  This
> attack is a little of a stretch on convenience for the attacker, but is
> feasible.  The end conclusion is really that key introduction for key
> indexes (names, IPs) should only occur when specifically authorized by the
> user and following a fingerprint display, never automatically.
> 
>   Robert N M Watson 
> 
> robert at fledge.watson.org              http://www.watson.org/~robert/
> PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
> TIS Labs at Network Associates, Safeport Network Services
> 
> 
> On Thu, 24 Feb 2000, Brian Caswell wrote:
> 
> > 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 at ruff.cs.jmu.edu>  
> > If I could load the world into vi, the first command I would use is:
> > %s/Windows NT//gi
> 

-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information