42

What are some of the security concerns and reasons either for or against allowing X11 Forwarding. I have generally taken an approach of not allowing it under the blanket guise of security. Recently, I had a user indicated that they thought that the security implications of resulting from allowing X11 Forwarded sessions were negligible. I was curious to learn more about what the harm is in allowing X11 Forwarding and why one might want to allow it.

John
  • 1,009
  • 3
  • 11
  • 16
  • 2
    See also the more general question [Risks of ssh to an untrusted host?](http://security.stackexchange.com/q/7480) – Gilles 'SO- stop being evil' May 09 '12 at 20:59
  • 1
    This doesn't make sense. The setting for disabling X11 forwarding is on the server. So if the server gets compromised, the attacker (who now has access to the server) can easily re-enable this feature even if it has been disabled earlier, and you are back to where you started, which is the ability to compromise the client. – NeeHow Jun 24 '15 at 16:31
  • 1
    > With X11 forwarding, the server is likely to gain shell access to the > client. Could anyone confirm this? I tried to google it but couldn't find anything. Is there some further reading about it? – Diver Jun 15 '16 at 09:26

3 Answers3

42

The implication of X11 forwarding is that it opens a channel from the server back to the client. In a simple SSH session, the client is more trusted than the server: anyone in control of the client can run commands on the server (assuming shell access), but the converse is not true. With X11 forwarding, the server is likely to gain shell access to the client.

In a text session, there is a limited channel from the server back to the client: the server determines the output that is displayed on the client, and can in particular try to exploit escape sequences in the terminal running on the client,

In an X11 session, the server can send X11 commands back to the client. X11 was not designed with security in mind, it was designed with the idea that all programs that you're displaying are run by you and hence trusted anyway. By default, SSH subjects commands from the server to restrictions through the X11 SECURITY extension. The SECURITY extension disables some obvious attacks such as keyboard grabs and key injection, but allows others like focus stealing.

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
  • 4
    Just to add to this, if I remember correctly, about 4 years ago, OpenSSH's `-X` behaviour was changed to use the X11 SECURITY extension by default, but it can still be disabled with `-Y` (or `ForwardX11Trusted`). (See [man page](http://linux.die.net/man/1/ssh).) – Bruno May 10 '12 at 00:45
  • 2
    The poster seems to be asking in regards to whether to allow or disallow X11 forwarding in the server config, however your implication is applicable only in deciding whether the client configuration should allow or disallow X11 forwarding. So is there a security implication in allowing X11 forwarding on in the SSHD server config? – David M. Syzdek Apr 19 '16 at 02:23
  • 2
    @DavidM.Syzdek I don't know of any security concern in allowing it on the server side. I don't know why it isn't always allowed (for a general account, that is — for an account that can only run a specific command, allowing port forwarding does increase what the account can do). – Gilles 'SO- stop being evil' Apr 19 '16 at 11:09
14

Let's say I open a SSH connection to someserver, with X11 forwarding enabled. The primary risk is that if someserver is malicious, then someserver can do all sorts of nasty stuff to the windows/applications I have open on my own computer.

For instance, someserver can open up windows on my computer, can close other windows I have open, can spy on the contents of other windows I have open, can spy on the keys I type into other windows, can inject spoofed keystrokes and mouse events into other windows I have open, and generally just mess with every other window I have open on my machine -- even if some of those other windows are local applications running locally.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • Maybe even pop up a dialog that says something crashed and requires your password for sudo access. – munchkin Jun 25 '15 at 06:19
  • 1
    How does something like XQuartz say for example on macOS get access to all windows other than the one that it created and opened for a particular session? Does't the OS prevent something like that? – Makmeksum Apr 13 '20 at 01:29
-1

One solution to the risks of X forwarding over ssh discussed in the other answers would be to use what might be called a masquerade X server, which is not really an X server but presents an pseudo X interface and a pseudo X screen to the client software on the container, while passing some X work off to the real X server behind it. The pseudo X screen is displayed as a single X window on the host actual X desktop.

Even though it wasn't intended as a security tool, Xephyr does fit that description.

For that reason I wrote a javascript program to create an lxd/lxc container from a vanilla ubuntu image, and populate it with firefox, openvpn, Xephyr, and pusleaudio.

https://github.com/craigphicks/browser-on-lxc-vpn-xephyr

https://www.npmjs.com/package/browser-on-lxc-vpn-xephyr

I wouldn't make any strong security claims about - it was a proof of concept exercise.

Craig Hicks
  • 425
  • 3
  • 6