openssh unix dev - Mar 2005 - bug: X11 forwarding silently falls back to ForwardX11Trusted=yes

On 2005-01-11 at 6:36:13 Darren Tucker said:
> kochera at postfinance.ch wrote:
> > We upgraded from 3.7.1p2 to 3.9p1. The behaviour of the X11 forwarding
> > changed significantly, it is much slower. See below the truss output
> > (server side which runs 3.7.1p2) an check for the timestamp (6 seconds
> > delay). Do you have any idea what may causes this behaviour? Platform
is
> > Solaris  5.9 Generic_117171-05.
> 
> One thing that changed was the use of untrusted xauth cookies.  You can 
> use the previous behaviour by putting "ForwardX11Trusted yes" in 
> ssh_config.
> 
> The other possibility I can think of is some kind of name resolution or 
> IPv6 wackiness: you can try "UseDNS no" and "AddressFamily
inet" in
> sshd_config and/or start sshd with the "-4" option to test those.
I actually just tracked this problem down.  When "ForwardX11Trusted"
is
"no", the local ssh client will attempt to requested the new generated
cookie with xauth, but times out in the attempt, and falls back to 
forwarding the trusted cookie.  (I think this is a bug: it should emit a 
failure, since it should never default to a _less_ secure option.)

The cause of the failure (for our situations) happens one a double-ssh.  
For example, we have people ssh'ing into our shell machine from home, and 
then ssh'ing to their project machines, where they run X11 programs.

The code just before the xauth calls (in ssh.c:x11_get_proto) attempts to 
figure out if the X11 screen is local to the machine or not.  It assumes 
that "localhost:..." means it should rewrite the display to
"unix:...".
However, this breaks our situation, since the display is "localhost"
due
to it being forwarded via sshd.  Since unix:... doesn't exist, the xauth 
hangs, and then times out, causing this delay.

A "true local" display shouldn't have a host part at all
(":0.0", for
example).  Perhaps that would be a better way to test for local displays?


(please Cc any replies, I'm not subscribed)

Thanks!

-- 
Kees Cook
Core Services
x1918