James Stephens

Imagine you are the administrator for a site that wisely doesn’t allow telnet in, but does allow ssh. What I am going to explain now is a way in which your security can potentially be seriously compromised.

Consider an ssh connection from a machine external to your network, E, to a machine I inside your network. We are going to assume that either X-forwarding within ssh is disabled, or that the user in question doesn’t know about X-forwarding and decides to set the display manually instead (this happens a lot more than you might think).

In shell window A, on machine E;

E> xhost + $I
E> ssh $I
I> setenv DISPLAY $E:0.0


In shell window A, we now open another shell window, window B.

I> rxvt &

E> lsof -i
ssh 1283 root 3u IPv4 1734 TCP $E:739->$I:ssh (ESTABLISHED)
X 995 root 17u IPv4 1752 TCP $E:6000->$I:4511 (ESTABLISHED)


It is clear that the connection to the X server on E is separate from the ssh connection. What this means is that anything typed in xterm A is naturally encrypted because it is part of the established ssh connection. However, what you may not realise is that anything typed in B is not encrypted at all. So, if you run tcpdump or snort on E and look at the captured packets you can see everything that is echoed to xterm B directly in the snort output. Now, don’t fall into the following trap: If you think that passwords are safe because they are not echoed to the screen, you are wrong. They might not show up in the tcpdump or snort output as human-readable characters, but they are sent across the wire in the form of X keyboard signals which are part of the display and can be captured by running a capture and decode utility at either end of the connection. A program called xkey will demonstrate this fact. It works by opening a connection to the accepting screen and requesting any X traffic. When it gets the traffic …….. which it is assured of doing because it works over TCP, it decodes it. Voila!, passwords and all.

So there you have it ……….. the user on E unknowingly compromised the security on I. Taking this one step further, one can say if the original xhost command was a more generic “xhost +” on machine E then anybody in the world can potentially access the keystrokes in window B on machine I.

There is only one way to stop this I can think of to stop this, and that is to prevent TCP initial SYN packets out to “external” X-servers running on ports 6000:6010 or thereabouts with a firewall rule.