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=20
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=20
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. =20

The only thing that is required for the client system to be compromised=20
is for the client to remotely log via ssh (with X11 forwarding enabled)=20
into a compromised server.

Allowing X forwarding seems to be turned on by default in SSH1, SSH2,=20
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. =20
The "issue" in SSH X11 forwarding is not new.  SSH has added to the=20
security of X11, but by no means does the use of SSH secure X11.

--=20
Brian Caswell <cazz@ruff.cs.jmu.edu> =20
If I could load the world into vi, the first command I would use is:
%s/Windows NT//gi

--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4tbFHac/1Eph0QDwRAoL5AJ9p/DedW7QzcYJiuSuBSjdqVo9zPQCgid6n
gnUCAorTStQc4OTT+7gg72A=
=3kz7
-----END PGP SIGNATURE-----

--UlVJffcvxoiEqYs2--