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.
SQLite
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.
X2Go client-side Printing
Might be exploited if someone becomes x2goprint-user
X2goServer == CUPS Server, latest implementation (as of 20110909):
cups-x2go CUPS backend runs as root
as root the backend launches x2goprint (without sudo!!!)
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.
X2goServer != CUPS Server:
The Cups-server connects the x2go-Server as x2goprint-user using ssh-key auth.
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.
Possible solution 1
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)
Possible solution 2
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
Pulseaudio
No known exploits / Privacy issues
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.
Solution for privacy
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).