Jump to content
Sign in to follow this  
NagChampa

X forwarding over SSH, the security risks

Recommended Posts

I'm not sure if this should go here or Open Source Software, so I picked this one as it's been a topic in here recently.

 

One of the handiest features of the SSH protocol is built in X forwarding. What this means is with a -X, or -Y, added to your ssh command, the necessary ports and such are setup at each end, and DISPLAY variables set so that you can run a remote X app and have it show up on your local X server.

 

Because SSH has built in compression, and because only the drawing instructions need be sent from the remote application to your local X server, it's a lot more efficient than VNC or other remote GUI methods.

 

The question remains though, why the -X and -Y

 

From the ssh manpage we get:

 

-X	  Enables X11 forwarding.  This can also be specified on a
			 per-host basis in a configuration file.

			 X11 forwarding should be enabled with caution.  Users with
			 the ability to bypass file permissions on the remote host
			 (for the user's X authorization database) can access the
			 local X11 display through the forwarded connection.  An
			 attacker may then be able to perform activities such as key-
			 stroke monitoring.

			 For this reason, X11 forwarding is subjected to X11 SECURITY
			 extension restrictions by default.  Please refer to the ssh
			 -Y option and the ForwardX11Trusted directive in
			 ssh_config(5) for more information.

	 -Y	  Enables trusted X11 forwarding.  Trusted X11 forwardings are
			 not subjected to the X11 SECURITY extension controls.

For many people, this doesn't really clear much up. I know I was still stumped. But here's a summary of the issues:

 

-X enables untrusted X forwarding. This means that clients run on the remote machine will be restricted in how they access the local X server. This makes things such as key logging, screen grabbing (taking screen shots) and window management impossible. While these events could be legitimate uses of the remote X application, they are dangerous, and open up your X server to the remote machine.

 

Unfortunately, some X applications require the use of some of these restricted behaviours, one of which is Mozilla Firefox. This application will not start over as an untrusted X client. If you try, you'll get the message:

 

X11 connection rejected because of wrong authentication.
The application 'firefox-bin' lost its connection to the display :10.0;
most likely the X server was shut down or you killed/destroyed
the application.

This is where -Y comes in. This allows remote X applications to run trusted in your local X server. According to here, it actually avoids the local X trust mechanism entirely. This means Firefox will have not trouble starting, seeing the X server as no different from one running locally to it.

 

However, the way many distributions are set up, or the requirements of the X server, most of the time the X server on your local box is running as root. I believe most distributions setup X to execute setuid root anyway, so even if you tried to manually start the application yourself, it would gain root permissions. While a normal user on the remote box will not be able to access the Xauthority for your session, there is nothing stopping someone with root access to the box gaining that authority data, and taking over your local X server.

 

For this reason, it is imperative that when you set up a trusted X forward to your local X server, you truly do trust the remote box. Even if you trust the administrator of the system, if the system is at all compromised, how can you be sure?

 

I've read a few articles about the security issues, and many of them warn people off using X forwarding at all, let alone trusted X forwarding. However, there is one way that you can do this in a safer manner.

 

Reading this article, which mentions using VNC over an ssh tunnel as the most secure, if not sluggish, methods of remote GUI access. The key here is that the local VNC client is not running as root, and the programs running in the remote box have no access to the parent X server.

 

Not wanting to have to use VNC, which I find far to inefficient, I realised there was another option. Xnest.

 

Xnest is an X server in an X server. It acts as an X client to your real X server, and acts as an Xserver to those clients you wish to start in it.

 

It runs as the user who executes it, and its clients have no access to the parent X server. You effectively sandbox any X clients running in it from your main X server. While I believe this is a safe option, I plan to do more research into how secure it truly is. While I believe this is safer than running trusted remote X apps on your parent server, I wouldn't rely on this for security where security was important. Also read http://www.greatcircle.com/firewalls/mhona...7/msg00288.html

 

Now, to get things going, first you'll want to make sure you have the Xnest program installed. I believe it comes installed with Xorg, however check your distros documentation on where to get it if you don't have it.

 

If you've got it, starting it is easy enough. The trick to keep in mind is that the display :0 will be taken by your current X server, so you need to give it a new display, lets give it :1. To start it, all you need do is from a terminal:

$ Xnest :1 &

You should get a window popup with the standard X crosshatch background. Now you have a choice to make. you can either run a local window manager, or start one on the remote machine. Either way, from the same terminal you started your Xnest server from, set your DISPLAY variable to the new server:

$ export DISPLAY=:1

Now if you want to start a local window manager, start it from the terminal. You can then start an xterm (or other terminal app) in the nested X server and continue working from there, or you can keep working from your current terminal.

 

Next you need to establish your SSH connection. No change here:

$ ssh -Y user@host

As you are in a nested X server, a remote user could only gain control at best of that server. If you are planning on running a remote window manager, you must use -Y. You can of course use -X if you don't require trusted apps.

 

Once you have your ssh connection established, you should be able to run remote X apps and have them show up in the nested X server.

 

You could script the process if you wished.

#!/bin/bash
# remote X Session
Xnest $1 &
DISPLAY=$1
ssh -Y $2 $3

Save that in your path somewhere as sshx, then call it like this:

sshx display [user@]host command

The [user@] part is optional

 

For me to connect to another machine on my network, and start the remote window manager wmii I could use:

sshx :1 nagchampa@sandalwood wmii

So, there you have it. A safer, but still usable option for remote X applications.

 

Links:

http://padraic2112.wordpress.com/2007/07/0...sions-over-ssh/

http://padraic2112.wordpress.com/2007/07/1...remote-display/

http://books.google.com.au/books?id=NZJsza...tsec=frontcover

http://www.greatcircle.com/firewalls/mhona...7/msg00288.html

Share this post


Link to post
Share on other sites

I've run into a slight problem using Xnest that seems to be showing up in bugzillas everywhere. Currently it seems starting a remote xterm to run in Xnest will not work. Something in the way Xnest handles fonts, and the way xterm tries to open them. Just thought I'd give a heads up.

Share this post


Link to post
Share on other sites

I'm not sure if this should go here or Open Source Software, so I picked this one as it's been a topic in here recently.

 

Because SSH has built in compression, and because only the drawing instructions need be sent from the remote application to your local X server, it's a lot more efficient than VNC or other remote GUI methods.

Awesome post, but I am not sure I agree with the above. Can you clarify a bit more why you think this is so? VNC implementations can have compression and run over TLS, so..

Share this post


Link to post
Share on other sites

Yeah, VNC only sends the drawing instructions, and much more efficiently than SSH.

Bzzzt.

 

Don't worry, you'll get a consolation prize of an imprinted pencil.

Share this post


Link to post
Share on other sites

Yeah, VNC only sends the drawing instructions, and much more efficiently than SSH.

X11 sends the instructions, VNC sends JPGs of the whole screen over and over.

 

 

I've found an uncompressed X11 Over SSH Session to be much quicker than VNC

Share this post


Link to post
Share on other sites

From what I understand of RFB, most of the demands are put on the Server, not the client.

 

X forwarding results in more processing on the "client" (actually running the X Server).

 

Also, almost any *nix computer comes with the software installed AND running to do X forwarding over ssh, whereas a VNC setup would require even more setup and running software.

Share this post


Link to post
Share on other sites

RFB still sends data on a pixel by pixel basis, even after compression that's way more than a compressed X11 connection. X11 Forwarding just sends the Geometry and any required images to the cleint.

In most circumstances you will find X11 forwarding to be faster.

Share this post


Link to post
Share on other sites

From what I read in the RFB spec, it can send shape geometry. The issue is you have it being translated from X on the remote end to RFB, then the client has to display it. Also, if you run a local window manager on the client end with X forwarding, you reduce even more or what needs to be sent, ultimately limiting drawing to individual windows, with the rest handled locally.

Share this post


Link to post
Share on other sites

X forwarding is fine for a local network, and even preferred for *nix systems, but it cannot replace what VNC was designed for. SSH works well for non graphically intensive apps, like gedit. Have you ever tried using firefox over forwarded X? VNC handles it fine, and on a bad connection. VNC is generally faster than SSH X forwarding. Also, to say that most *nix computers would be set up for SSH X forwarding but not VNC is false. x11vnc is included as a part of X.

 

Check again page 22 of that linked paper. RFB sends updates only when necessary, and more efficiently than just forwading. Think about this for a second, forwarding vs a protocol designed to efficiently display a remote desktop with as little information as possible. Also, it is entirely possibly to use VNC through SSH, which can be faster than simply using VNC by itself, and will provide better security.

 

Edit: removed mixed up info

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×