• In X2Go Server versions prior to 4.0.1.12 (or 4.0.0.10 for the Baikal LTS release branch), there used to be a root exploit that got reported and fixed around X-mas 2013.

• In X2Go Server versions prior to 4.0.1.12 (or 4.0.0.10 for the Baikal LTS release branch), there used to be a root exploit that got reported and fixed around X-mas 2013.

<note important>Might be exploited if someone becomes x2goprint-user</note>

1. X2goServer == CUPS Server, latest implementation (as of 20110909):
   1. cups-x2go CUPS backend runs as root
   2. as root the backend launches x2goprint (without sudo!!!)
   3. x2goprint script changes owner ship of PDF file and pushes it into SSHFS share towards the X2go client.
      • using X2go printing locally (X2go server == CUPS server) then security (sudo) is not an issue any more(?)
        • Nope still is (not a big one, though): Using CUPS the user can easily be faked, allowing to fill someone else's quota or print at their home printer.
2. X2goServer != CUPS Server:
   1. The Cups-server connects the x2go-Server as x2goprint-user using ssh-key auth.
   2. x2goprint-user executes sudo to change the ownership of the PDF file and pushes it into SSHFS share towards the X2go client.
      • This script can currently be exploited.
      • If someone becomes x2goprint he might become root.

• Start a local cups-server for every user
• Server listens on a File-socket owned by the user
• Add a PDF-Printer to that server (as the cups-user runs as that user, there should be no issues with file permissions)
• Import printers from global server
• + Secure solution, as no other user is involved
• - Every user needs an extra instance (The extra memory usage should not be too much)

• Write a simple C-Program 'x2goprinter' that is run as the user who wants to print unsing the s-Bit
• The Program writes stdin to argv[1] in the printing-directory
• It also checks whether the user is x2goprint or root
• + Can be easily adopted
• - x2goprint must be installed by the client
• - s-bit → Needs security checks

<note>No known exploits / Privacy issues</note>

• Currently Pulse-Audio authentication using a cookie-file is used.
• No option of encryption, but can be tunneled via SSH.
• When using the TCE the client has only one user. Therefore the following user may get sounds from the previous, suspended user, if not tunneling pulseaudio.

• Start pulse-audio server on the server
• use sink-tunnel to tunnel to the clinet
• Disconnect sink on suspend
• Send sound to null-dev
• This also solves issues if the client get disconnected unexpectedly.

Morty: I looked into this recently (End of 2011). Unfortunately, due to the buffering done on the server, this might start to “swing” (playback getting faster and slower again and again).

• This issue has been fixed: x2goagent/nxagent opens a port 6050+ and binds to all network interfaces. This should be tweaked so that x2goagent/nxagent binds to localhost only. Refer to: http://article.gmane.org/gmane.linux.terminal-server.x2go.user/430
• Now, only for XDMCP session the listening port 6050+ is opened (otherwise XDMCP queries do fail)
• If people need x2goagent listening on TCP, it can also be re-enabled in /etc/x2go/x2goagent.options.