Package: x2goclient Severity: grave Tags: security
Hi.
From: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714588
It seems that per default (and I even found no way to disable it) x2goclient (and perhaps other related tools?) transmit the content of the clipboard to the remote host.
As this may easily contain passwords or other sensitive information, this is a extremely critical hole.
Cheers, Chris.
On 13-07-01 04:56, Christoph Anton Mitterer <calestyo@scientia.net> wrote:
Yes, other related tools like X11. x2go is basically just a faster version of the traditional xforwarding. In X11 every client can always access the clipboard/selection/etc., so you will also have the same security problems (by design). E.g. 'ssh -X user@evilhost "xclip -o"' demonstrates this.
As this may easily contain passwords or other sensitive information, this is a extremely critical hole.
I disagree, this is not a hole at all, it works as intended. Its just that users are often not educated about the implications of passing around passwords via the clipboard etc.
But I concur that the ability to switch off clipboard/selection/... forwarding in the x2goagent/x2goclient would be nice to have. Patches are of course always welcome.
Ciao,
Alexander Wuerstlein.
On Mon, 2013-07-01 at 13:43 +0200, Alexander Wuerstlein wrote: this as well... like as if Gentoo would say "if Debian breaks their
OpenSSL entropy, we should do so, too"... o.O
Cheers, Chris.
On 13-07-01 15:03, Christoph Anton Mitterer <calestyo@scientia.net> wrote:
It isn't like that at all, X11 clients and servers have to comply with the respective parts of the protocol. If the protocol demands insecure behaviour, its a design bug, or maybe, like in this case, a compromise nobody likes: Since in X11 clients handle all the shortcuts and mouse button events, since clients or toolkits handle the widgets, the only option to implement C&P is to have clients ask the server for the clipboard or selection contents. Its more a "there is no other way to do it except to make it unusable" kind of problem imho.
I'm not only talking about 'xhost +' and the like, this would of course be a major problem for more reasons than only the clipboard. And if you wouldn't trust a host with 'ssh -X', then you also shouldn't trust it with x2go. Just think of x2go as a variant of 'ssh -X' with image compression and some extras. X11 protocol firewalling is not really one of those extras. And since the x2goclient will always run in your local X session, it will always be able to read your clipboard.
In a way, yes. Afaik you can avoid certain attacks of the "I'll attach to the root window and get all key events" kind since windowed x2go sessions give you a separate root window. But I imagine there are more problems out there nobody thought of yet.
Ciao,
Alexander Wuerstlein.
Hey Alexander.
First,... I assume you're one of the NX/X2go developers?
On Mon, 2013-07-01 at 16:01 +0200, Alexander Wuerstlein wrote: that below:
With respect to the issue (transferring the clipboard) itself: Don't get this in anyway offensive! But I think it's plain simple:
It may easily happen that people copy (by intention/accidentally or even automatically by software) stuff to the clipboard which contains sensitive information, which in turn can be anything from passwords to my private love letters ;-)
And people don't see x2go (or VNC, or rdp) like a direct access to their X server (as in plain X forwarding with xauth and that like). This might be a misunderstanding... but it's how many similar such "VNC-like" connections (i.e. a screen output into _one single_ X window) work. E.g. when I connect to my qemu virtual machines, I don't have to worry, that the VM can overtake my X server,... the same for Virtualbox... and I hope/believe for VNC/TightVNC/etc. and rdp connections (rdesktop and friends).
This includes that users don't expect (or at least they shouldn't have to) that such connections allow wiretapping, e.g. if such a system supports audio forwarding... it shouldn't allow the remote side to activate my MIC and listen to what I say/sing/etc.
The same holds true for the clipboard... at least per default it shouldn't be ever sent to the remote side (or vice versa)... and IF one activates it... people should be warned with big warnings what this could mean.
That this can indeed lead to compromise showed a recent attack we've had on one our institutes' machines, where sensitive information was caught via an X2go connection and later on used for other attacks.
Now for the technical side... admittedly I don't know the details of how NX interacts with X... but there must be some way to achieve blocking of the clipboard sync. Even if the protocol demands to send some content,... well then simply hook in an clear it always (per default).
Now more off topic about how NX interacts with X:
I understand that NX is not like VNC, where it's more like send the pixbuffers.... and where you obviously have not much security problems in terms of taking over the local X server, since it's more like displaying JPEGS (of course VNC has much other security problems).
I haven't found out what RDP actually does... but I'd assume it's rather similar to VNC?
Now with NX I understand it's compression at the X protocol level, so "no JPEGs being transferred"... but where do remotes X protocol go to? Directly into the local X? Or is it taken by NX/X2go and rendered as if NX/X2go would be an X server that is displayed in a _single_ window of another one (i.e. like Xephyr)?
I mean don't take this rude... but for me this basically makes NX unusable, since I basically only use it to connect to more or less untrusted nodes. If that means these can take over my X, or even more... than good night :-/
Cheers, Chris.
Hi, Chris.
One additional note: it's possible to turn on clipboard forwarding in RDP and VNC (and it's a very useful thing) but AFAIR in most clients _one have to specify it implicitly_ (and sometimes there's a separate option that allows some restricted clipboard access, for example: copying from remote to local but not vise versa). May be someone will make a patch to implement such options in X2Go.
On Tue, 2013-07-02 at 11:10 +0400, Nable 80 wrote: the "secure" screenshots)... But moreover... it's nowwhere really documented (at least where people easily see it) - I didn't find it at all. When one goes into the ssh/ssh_config manpages and read about the X forwarding options... strongly warns one about the security implications (which are basically like giving root to the remote). When one reads the xauth manpage (and the fact that there is a dedicated program which one needs to grant privileges)... one reads about what one does.
With X2go/NX.. there seem to be no such emphasised warnings in the obvious places.
But to be honest... the clipboard sniffing problem seems to be "boring" compared with the "direct interaction" with my local x server... at least with respect to my security thinking...
Oh and no one from the developers should get me wrong: I do see that NX is very nice and great with respect to it's speed, which is probably not doable with VNC like screenshoting.... but a) I think people are not warned/told enough about what happens (technically)... and b) clear information misses... on what could actually happen (in the sense of "is it secure as it is, or can this direct communication with the local X server cause troubles - perhaps there are none... and they only issues where those with the global root window.. which seems not possible with NX? But perhaps there are!).
Cheers, Chris.