How is this different to a malicous user (with root privilege) just taking a copy of the cookie out of the connected users .Xauthority file, placing this information into their own .Xauthority file and then connecting to the X-server on the SSH client's side. I do not think that there is anything particularly significant about the possibility of Trojanning xauth. The significant point here is that, by default, an SSH client gives too much trust to the server it is connecting to. Perhaps consideration should be given to changing this default such that a parameter has to be passed to SSH when a session is started to allow X11 connections, without this parameter X11 connections are not allowed. The issue here has nothing to do with xauth and everything to do with the trust granted by SSH. If you use SSH to connect to boxes that you don't trust or can't be confident are secure then you should be concerned about this. The major threat I see here is that a rooted box could be used to gain access to a secure box through the SSH tunnel, even if the secure box is behind a firewall that only allows outbound connections. Yours, David Pybus. -----Original Message----- From: Bugtraq List [mailto:BUGTRAQat_private]On Behalf Of Brian Caswell Sent: 24 February 2000 22:32 To: BUGTRAQat_private Subject: SSH & xauth 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 <cazzat_private> If I could load the world into vi, the first command I would use is: %s/Windows NT//gi
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:37:26 PDT