SSH & xauth (fwd)

[Gary E. Miller]

Yo Mike!

I only run X clients (Xwin-32) on my WinXX laptop.  From the laptop
I use SecureCRT to connect to remote UNIX hosts running OpenSSH. Then
I tunnel X in the SSH session.  The way you describe is EXACTLY
the way that I have my Xwin-32 set up on the WinXX host.  Each time
an X window opens on my laptop a box pops up to ask me to allow/deny.

This usually works find unless a popup gets buried under other stuff
and I do not see it in time.

RGDS
GARY

On Fri, 3 Mar 2000, Mike Fisk wrote:

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

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