Bad Security 201 – More On Remote Display

Related to this post is the question… “What’s the best way to get a graphical interface on a remote machine? “

If the remote machine is Windows, you run Remote Desktop Connection (from a Windows box) or rdesktop (from a Linux box) and call it a day.

If the remote machine is Linux, barring some lower-level protocol solution like IPSec, you basically have the following options:

• Native X-forwarding
• X-forwarding over SSH
• VNC
• VNC tunneled through SSH
• Something like FreeNX (see below)

 

Native X-forwarding

Uses an unencrypted channel, and thus any traffic is wide open for stealing. Since it’s unencrypted, and since the local x-server only has to render the gui info piped from the remote machine, it’s pretty fast, relatively speaking, although there is no compression, so you can see performance issues if you don’t have good network bandwidth. But, since it’s unencrypted, it’s pretty much suicidal on an open network. Anyone who does this ought to be shot. It’s about 1000 times worse than doing remote admin using telnet, since (in addition to handing away control of the destination box) you’re potentially compromising your local machine. Brrr.

 

X-forwarding over SSH

Uses an encrypted channel, preventing eavesdropping, at a cost of performance, since everything has to pass through the encryption. Security-wise, still pretty horrid since many applications on a remote machine don’t work properly unless you force the connection to run “trusted” (this is generally stinky and ought not to be done).

If the remote machine is compromised, you’re handing over your local desktop to the compromised machine when you connect to it. If the remote machine is reasonably trustworthy, well, this may be an acceptable risk, but unfortunately if/when you tell anyone how to do this they’re going to connect to *untrustworthy* boxes (like, their own machines or machines set up elsewhere by people who don’t know what they’re doing), so I generally consider this to be a bad idea. You see lots of posts about X-fowarding over SSH on the web, few of them mention the risks involved.

Anyone who does this ought to go into sysadmin time-out, or shot if they’re connecting to untrusted machines.

 

VNC

VNC has a DES encrypted challenge-response for the login process, but a 56 bit key and a 8-character password are pretty trivial to crack. In addition, all subsequent traffic between the hosts is in the clear, due to performance issues, so you have the same snooping problems you do with native X forwarding. I have professional experiences of instances of VNC sessions being brute-forced and subsequently had compromises, escalated because the user in question had sudo.

Anyone who does this also ought to be shot, as per Native X-forwarding. I’ve talked about this ’till I’m blue in the face, and people still do it, and it makes me nuts.

 

VNC Over SSH

Setting up an SSH tunnel and then piping all your traffic through it solves the “in the clear” issue of using native VNC. There are performance issues, since VNC itself has cruddy compression, and tunneling everything through SSH can bog things down. Since VNC does not require the local X server to talk to the remote machine, this is much better than X-forwarding over SSH, as you’re not treating the remote machine as a trusted X client. In addition, VNC runs as a user-level process, so if there is an hack in the wild, the worst thing that can happen is that someone hijacks the user account on the local machine; whereas if you’re doing X-forwarding, the local X server (running as root) is exposed to input from the remote client, not terribly keen about that.

VNC over SSH, in my experience, is so “performance-wise” annoying that it is a barely acceptable solution. Their compression algorithms are just plain bad.

Note, if you’re going to do this, you need to make sure that the VNC Server only accepts connections from localhost, using a firewall of some sort, else the Internet Bots will eventually crack in.

 

FreeNX

http://openfacts.berlios.de/index-en.phtml?title=NX_Components

FreeNX uses SSH as a backend for encryption, but adds compression and caching, and is supposed to make remote graphical connections usable. I’ve heard good things, but I’ve never actually tried it (I only connect to Linux boxes remotely using a terminal), so I can’t give a comprehensive review. Reading the documentation leads me to believe that if someone actually needs remote GUI, this is probably the only real, current alternative that isn’t full of gaping ugly security holes or (potentially) horrid performance issues. You may want to explore it (or some other alternative similar to it) as a solution.

ed: Coworker Dave has used FreeNX, reports that it works as advertised, and does remote-to-local audio and video forwarding functionally as well. FreeNX is available in many repositories, and apparently comes with Open SuSe and Mandriva at least. FreeNX is also part of the FreeBSD ports collection (/usr/ports/net/freenx)

 

Remote Desktop Protocol

RDP solves pretty much all of the above, but the remote box needs to run Windows, since there isn’t currently an RDP server for X (and, since RDP is proprietary to Microsoft, unlikely to be forthcoming). Which is too bad, since RDP is functional, supports high levels of encryption, and even (most recently) supports server keys, so you have a destination host verification channel like SSH does.