16

I am using rdesktop client on Linux to connect to windows machines. If some of these machines were compromised by some evil malware/virus/worm/trojan, is there any way for the malware to "jump" to my computer over the rdesktop connection?

I have always thought this is impossible, but recently I have read that similar technology, x2go is inherently insecure.

EDIT

To clarify my question, I am mostly interested whether the rdp protocol (or session) can be potentially dangerous for the client.

I don't understand the internals of the rdp protocol. But it seems to me, if the rdesktop client is just rendering images/bitmap then there is not much a potentially compromised server can do. If, on the other hand, the rdesktop client is interpreting some commands sent from the server, it could potentially be exploited.

For analogy: Modern browsers do not just display static HTML webpages. Instead, they interpret Javascript, Flash, ... Is a rdesktop client similar in that it interprets potentially dangerous commands from the server?

If the only think the client does is rendering images, than apart from some bug in rendering library, it cannot be exploited. That would be comparable to a image viewer viewing jpg images.

EDIT 2

Are there any configuration options for the linux rdesktop client which I could use to make the session more secure? For example, I don't need "disk-redirection" or sound. Actually, I only need picture of the screen and clipboard (ctrl+c, ctrl+v).

From what I could read in man rdesktop, disk redirection and sound are not turned on by default. Are there perhaps some features which are turned by default, and which might bring potential security problems?

Martin Vegter
  • 1,826
  • 4
  • 27
  • 39

3 Answers3

13

From a theoretical standpoint, you are connecting to a remote machine and it is sending data back to your machine. While in the normal context, this is just display, location type data, it is possible that some sequence of bits could be processed in such a way that it causes an exploit in your rdesktop or other tool used to make the remote connection.

With any connections and any type of program this is possible, a browser, an FTP client, etc.

If you are concerned about connecting to a remote machine here are some things you could try to reduce/mitigate your risk:

  • Load up rdesktop or your tool in a sandbox, virtual machine, live CD, etc. That way, if there is an exploit it does not compromise your core machine
  • Ensure that you are running the most up to date version of rdesktop or any client-side tool.

In terms of the malware jumping from machine to machine, it would need to know of and take advantage of some vulnerability in rdesktop and then use that mechanism to copy itself. If there is no exploit in the rdesktop application, it would be unlikely it could just "jump" by transferring the visual image. If you have some special version or enable some type of file sharing or file transfer, shared clip board, etc then it would be possible for the malware to utilize one of these channels.

A quick web search finds CVE-2008-1801, CVE-2008-1802, CVE-2008-1803, which describes a vulnerability in connecting to a vulnerable remote desktop server (the remote machine you would be connecting too).

In response to your edit:

It doesn't matter what the payload of the data is, file transmission, image, chat message, its all data. There is also control data, mouse position, refresh information, etc - a lot of data is needed just to keep the communication open and send updates. The compromised server can abuse the protocol by sending data which when processed by the client will cause a buffer overflow, etc. The data could be malformed or well formed. It's a matter of how those bits are interpreted. Even Photoshop or a Video editing program can have vulnerabilities when opening and processing data.

CVE-2012-4170 is an example of an exploit resulting just from the processing of an image.

To gain a better understanding of the RDP protocol:

In short, there is a lot of data being sent back and forth, and a lot of different and complex processing, there are lots of places an attacker could poke around for an exploit and a compromised or malicious server could send specially crafted packets to be processed by these bugs once found.

Eric G
  • 9,691
  • 4
  • 31
  • 58
2

One thing to bear in mind is that various shared resources can be enabled, sometimes by default - certainly in the Windows RDP client (I'm afraid I don't know the Linux client, but it's clear the protocol allows these shared resources.) For example, the clipboard is automatically shared between client and server by default, and local printers are made available; it's trivial to share your hard drive with the remote session, and (in the Windows client) this option, if previously used, remains selected when connecting to new servers. Presumably any malware on the remote box could then merrily infect that just like another mounted drive.

To sum up: even if the display-relaying technology is secure, other shared resources can introduce risk.

Daniel Hume
  • 121
  • 3
1

The rdesktop client supports resource sharing with the -r switch.

A local directory from the connecting PC can be shared with the remote server under a special share under \tsclient\<sharename>

-r disk:<sharename>=<path>,...

Redirects a path to the share \tsclient\ on the server (requires Windows XP or newer). The share name is limited to 8 characters.

So in case the remote server is infected with malware, it can potentially infect your files on the connecting PC through this special share. For instance CryptoWall is a ransomware known for encrypting files on network shares.

Gabor
  • 179
  • 5