OpenSSH v3.8p1 fails to interoperate for GSSAPI (Kerberos) and X-Windows

[Darren Tucker]

Before I start, 3.8.1p1 is out and fixes a number of bugs with 3.8p1, so 
you should consider using it instead.

Jim Carter wrote:
> Sometime between 2003-09-12 and the present, a draft RFC:
>     http://www.vandyke.com/technology/draft-ietf-secsh-gsskeyex.txt
> was issued defining gssapi-with-mic, which resists certain "man in the
> middle" attacks. v3.8p1 does only gssapi-with-mic; versions up to v3.7
> do only old-style gssapi.  There appears to be no ./configure switch to
> turn on gssapi-without-mic at compile time in v3.8.  The resulting lack
> of interoperability fully explains the symptoms seen.  There is no
> workaround.

Simon Wilkinson published a patch to enable backwards compatibility with 
"gssapi" authentication.
http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=107826289602763

> To get to the conclusions above I spent all of Saturday from morning to
> 22:00, compiling back versions of OpenSSH

Were the release notes unclear?  Both of these were documented in the 
"Changes since OpenSSH 3.7.1" section":

* ssh(1) now uses untrusted cookies for X11-Forwarding.
   Some X11 applications might need full access to the X11 server,
   see ForwardX11Trusted in ssh(1) and xauth(1) for more information.

* The experimental "gssapi" support has been replaced with
   the "gssapi-with-mic" to fix possible MITM attacks.
   The two versions are not compatible.

The full text of the release notes is:
http://www.openssh.com/txt/release-3.8

> In OpenSSH v3.9 I hope to see both gssapi-with-mic and old-style gssapi
> supported by both the client and the server.

Limited interop (with what is an obsolete internet-draft with known 
security problems) is provided by Simon's patch.

> In his posting the Debian developer points out that users are going to
> learn to make X-Windows work by setting ForwardX11Trusted true in their
> personal .ssh/config files, or putting -Y in their ssh shell aliases,
> where the sysop cannot discover and revert them when the current
> confusion on X security is straightened out.  Unfortunately,
> ForwardX11Trusted implies ForwardX11, so if I set ForwardX11Trusted
> true, every ssh will forward X, which is a waste and a possible security
> exposure.

That's only the "-Y" command-line option (which is a substitute for 
"-X"), ForwardX11Trusted does not imply ForwardX11 (at least in the 
current version, I didn't check older ones).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.