openssh & XEmacs gnuclient issue

[Chris Green]

Dug Song <dugsong at monkey.org> writes:
> it doesn't honor the XAUTHORITY environment variable? hrm. :-/

Its not that XEmacs doesn't honor XAUTHORITY, its that the XEmacs
process has one XAUTHORITY set ( on the original display's
.Xauthority ) where as the ssh display does not update XEmacs as to
where its credentials are.

the gnuclient program does not use it's Xauthority, it communicates to
the XEmacs process to open a window on the new display as well
(multiple display version of netscape's remote commands ).  A kludge
of a workaround is to merge the two ( and let the user shoot himself
in the foot to attacks via NFS/AFS ).

Now that I understand the problem from both ends.

> specifically, it protects the file's contents when the user's home
> directory is in NFS, or AFS. by using a local file, it prevents passive
> network sniffing of the Xauth credentials - see Ulrich Flegel's paper on
> SSH X11 vulnerabilities for details:
> 
> 	http://rootshell.connectnet.com/docs/ssh-x11.ps.gz

Thank you for the paper link. I hadn't thought about trying to protect
against people grabbing the cookie via nfs.  I'm going to have to do a
good bit more research before I'd venture to stick my foot in my mouth
and argue that protecting the key from that style attack is a
pointless.

My gut feeling is they could probably impersonate the file server,
replace an ls alias or something to that effect and gain access
another way. I would however grant that type of attack would be 
more difficult to achieve than simply snarfing a 80 char string and is
worth shielding, even though its not the only possible route of
attack.

By this logic, I've convinced myself to find another work around other
than patching openssh's xauth.

Thanks,
Chris
-- 
Chris Green <sprout at dok.org> <grapeape at uab.edu>
A good pun is its own reword.