Bad Security 201 – Remote X Sessions over SSH

There is a lot of misleading information on the web regarding the potential security problems using ssh with X-forwarding.

People don’t seem to understand the implications of the documentation. So, here’s the skinny. (technical note: this is written using OpenSSH 4.6.1p1, your mileage may vary with older versions).

OpenSSH (again, remember we’re talking about 4.6.1p1 here) supports the X Security Extension specification. In implementation, this means that the command ssh -X now by default treats the remote machine as an “untrusted” X client, and the command ssh -Y treats the remote machine as a “trusted” X client (actually, to be precise, it appears that the ssh -Y command bypasses the normal X trust mechanism entirely). We’re not going to talk about X’s security mechanism here, for the most part, except in the context of remote connections.

However, this command line behavior depends upon your ssh_config. In ssh_config, you have

• ForwardX11
• ForwardX11Trusted

By default, in OpenSSH, these two beasties are “no”. This is *not* the case in most deployed versions of OpenSSH, as packaged by your favorite distribution. In FreeBSD, they’re “no” (in NetBSD, I’d imagine they’re set to “no”, since Theo de Raadt is unlikely to override the default configuration of his most famous software package in his most famous BSD). In Mandriva 2007.1 (using the “medium” msec configuration for workstations) and Fedora Core 6, they’re both set to “yes”.

If ForwardX11Trusted is set to “yes”, then the commands ssh -X and ssh -Y are functionally equivalent. If ForwardX11 and ForwardX11Trusted are both set to “yes”, then the command flags are not only equivalent, they’re unnecessary… that is

ssh user@host command = ssh -X user@host command = ssh -Y user@host command

If ForwardX11 is set to “yes” and ForwardX11Trusted is set to “no”, then

ssh user@host command = ssh -X user@host command <> ssh -Y user@host command

So, what precisely does this mean? Well, you have to read the Xsecurity specification, and sit back for a while with a whiteboard and do some flowcharting to really get at the meat of this.

When you use SSH to do X-forwarding, what you’re actually doing is issuing a command on a remote machine, but you’re telling that command to send the GUI output back to your local machine’s X server for display (this makes the documentation difficult to read, because your common understanding of “client” and “server” here are going to be confused). The X Security Specification essentially says, “clients that are regarded as untrusted aren’t allowed to so certain things”. This means that (if you’re following the spec), you can connect to a remote machine using X forwarding and issue a command, and if the results of the command violate the “certain things” principle, you’re going to get an error instead of a result.

Side note – there are interesting problems here, since apparently the development crews of lots of client software packages don’t understand the X Security spec, so you get instances of odd behavior when you try and run a software application on a remote machine with X forwarding, where some things just don’t work right. This is apparently why Fedora Core 6 flips the ForwardX11 and ForwardX11Trusted to “yes”, in the interests of making things work.

So, supposedly, if you’re not using ForwardX11Trusted and you’re not using ssh with the -Y option, the application you launch on the remote machine can’t do evil things like take over your X server or keylog or take screenshots of your local display, etc. On the other hand, if you are using ForwardX11Trusted or you’re using ssh with the -Y option, you are bypassing the X Security Specification, which means that yep, that remote machine can do oodles of bad things to your local box.

Now, to make sure nobody misunderstands my position here, I generally think X forwarding is a bad idea. There are lots and lots of reasons why the SSH manpages say things that roughly translate into the vernacular as, “You ought not to load this gun and point it at your foot.” I think X forwarding to untrusted machines is a very, VERY bad idea, regardless of whether or not you’re using -X or -Y or what your ssh_config is… your X server on your local machine is running as root, not as a user-level process. Hooking that up to something running on an untrustworthy box is just foolhardy. Logging into a potentially compromised box via ssh is a bad idea, but at least there your ssh process is owned by your uid, so if you’re careful and paranoid you can limit badness. Somewhat. Remember that cascade failures are still abundant and can cause seemingly harmless things to break in really bad ways.

But don’t think just because you’ve read the OpenSSH materials that running ssh -X is going to provide you some level of protection…