On Tue, 2013-07-02 at 18:07 +0200, Alexander Wuerstlein wrote:

Well, in that aspect, VNC, RDP and x2go/NX are somewhat different. VNC and RDP basically started from some dumb kind of framebuffer and keyboard/mouse event forwarding. I knew (at least the VNC / RDP part)... and I started to realise the difference from NX ;)

X11 has a far larger amount of functionality and a huge system of extensions on top. Sure...

x2go/NX starts out from X11 and changes some aspects, pruning things that are slow or unnecessary (e.g. synchronous calls or uncompressed bitmaps). So while with VNC/RDP you have a very simple starting point from which you then can add some extensions like clipboards, with X11/x2go/NX you have everything and need to throw away stuff that might be bad. People are still in the process of figuring out the bad stuff, and generally its the far more hazardous direction of development. That's the problem... at least security wise... I mean it's no wonder that no sane person uses ssh -X on other hosts (especially untrusted ones)... the X protocol is so complex especially with all extensions.. and the typical attacks like global event grabbing or a "screen man in the middle attack" where a new full screen window tricks you into something evil... are probably just the simplest ideas of attacking.

...

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. Well, if you switch on audio forwarding in RDP, the other side can do exactly that... Sure... but at least you can turn it of (unfortunately many programs don't do so by default, neither do they warn you what switching it on means.

...

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. Do you have any more in-depth writeup of that attack so we maybe can learn from it and look at certain things more specifically? Well the problem is that I'm not really allowed to give much defaults (as you can see I also write from my private address)... Simply said... an attacker took over root on the remote system... and it seems he did just such sniffing stuff... :/

...

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).

Yes, that should be possible. Its just that someone has to implement it.

AFAIU, one would need to do that on the nxproxy level then?

...

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)? Some protocol calls are taken as is and passed to the local X, others are "transformed", e.g. made asynchronous, bitmap-compressed, etc. I see...

Well, the remote can't take over your system afaik. But there are concerns about the security of ssh -X vs. -Y. Keystroke monitoring is one of those concerns. Why don't you do the following: Not passing on any X stuff to the local X server... but staring an Xephyr server and sending it there?

Admittedly I don't really know how the Xephyr server itself does things (I once tried to ask the developers but got no reply)... and if that would really work like a sandbox ... At least my hope would be (as it was before with VNC/RDP/NX)... that any evil remote... could at least only take over the one single window... and in case of Xephyr... hopefully only the single Xephyr window.

First thanks for your answers...

I'd propose the following now: As this bug is now cluttered all over with two different issues

• clipboard sniffing and the warning when it was activated
• security measures and better documentation about what NX/X2go really does

I'd close this bug, and open two new ones, one for each issue... referencing that old bug... so that all topics can be discussed (perhaps fixed) in a more simple fashion.

Okay?

Cheers, Chris.